业务分库
按照业务分库，比如用户、商品、订单分库
带来的问题
- join 问题
不在同一数据库无法join，只能先查一个数据库拿到id列表，在去另外一个库查询 - 事务问题
原本在同一个数据库的不同表的操作可以在同一个事务里边，分散到不同数据库后无法通过事务统一修改。 - 成本问题
分表
- 垂直分表
把不常用且占用了大量空间的列拆分出去。带了的问题是原来只要查询一次就能获取所有所有列，现在需要查询多次 - 水平分表
-
路由
- 范围路由
按照userId的范围分表，特点可能分配不均（例如按照1000万分表，可能一个表有1000万另一个表只有1000），随着数据的增加平滑的扩充新表，原数据不动 - hash路由
按照hash取模分表，特点分配均匀，但是新增表所有数据需要重新分布，但是使用一致性hash算法可以优化 - 配置路由
增加一个配置表比如 user_router表 包含 user_id,table_id两列,优点灵活，缺点多查询一次表太大了性能也会不好
- 范围路由
join
需要多次join然后合并count()
多个表count()相加，实现简单去诶单性能较低。增加一个记录数表，性能优化了，但是复杂度增加了，必须要同步记录，但是又不能放在同一事务里处理，因为记录表插入失败不应该回滚业务逻辑order by
数据分散多个字表中，排序无法在数据库中完成，只能由业务或者中间件去分表查询每个子表中的数据然后汇总。
