记一个小问题:分库分表后的使用姿势

问题

收到一个问题,说有个列表在测试和预发环境排序没有问题,在线上就有问题。

然后定位是 sql 没有加排序。加上排序后就 OK了。

这是为什么呢?当然是因为测试和预发环境没有做分库分表啦。

测试环境里数据库只有一个,表也只有一份,所以列表的数据来自同一个库,同一个表。排序是按数据库的默认排序。

线上是有分库,不同数据库里的数据,取出来后再做聚合,没有排序的话是会有乱序的。

分库分表后的使用姿势

1) 排序

数据来自不同的表或库,首要的影响就是排序。按实现方案的不同,有不同的排序方式 , mycat , shardingsphere 会自动排序。

没有使用中间件的话,就需要自己实现排序。

2)数据查询聚合

查询后的数据在聚合时,需要发生些变化。因此需要尽量减少多表关联的查询。多表的关联查询比较考验分表的能力。分库分表没分好的话,那么在数据聚合时的性能压力会比较大。

我们团队的开发规范是禁止多表查询,包括子查询和 join 查询。

3)事务

数据分库后,事务是重点。

分布式事务,结合本地事务使用。

当然中间件能给你很多便利。

4)ID 主键

分库,分表后ID 最好用来做主键,不要用来排序。排序可以用时间或其他有标识的字段。

ID 生成则可以使用ID 生成算法或 ID 生成服务。例如:Snowflake 是 Twitter 开源的分布式 ID 生成算法,结果是一个 long 型的 ID。

5)读写分离

准确来说这不是分库,而是优化。读写分离,提高效率。

原文地址:https://www.cnblogs.com/ElEGenT/p/12839478.html