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

问题

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

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

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

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

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

分库分表后的使用姿势

1） 排序

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

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

2）数据查询聚合

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

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

3）事务

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

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

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

4）ID 主键

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

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

5）读写分离

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