最近在公司把一个项目的部分表水平拆成了64张，现已投入生产使用，记录一些实践过程中的问题和思考，写的不对的地方，各位客官老爷轻喷。
分表的时机
分库or分表or分库分表
方案设计（路由键的选择，平滑发布方案，容灾方案，数据源路由，读写分离等）
使用ShardingSphere遇到的问题和解决方案
1.分表的时机
这个其实取决于项目的发展速度，我所在的项目核心单表基量500w，日增长在10-15w，未来2-3个月日增长很快会发展到20w，40w，2个月前我们开始计划分表，当时的数据量是200w，日增长2w，尽量在核心单表数据量达到500w前完成拆分工作。
2.分库or分表or分库分表
决定了拆分，就开始考虑怎么做拆分，我们的方案是一期先做分表，分库暂不实施，这个基于开发资源，业务模式和发展的预测得出的结论，那也总结一下我思考的分库or分表or分库分表选择的依据
分库：适合数据量比较大，但是增速不快，比如，单表500w数据，增加到1000w可能还需要半年一年以上的时间
分表：适合数据量目前比较小，但是增速很快，比如，单表200w数据，增加到1000w可能只需要一个月的时间
分库分表：适合数据量比较大，增速也很快，比如，单表500w数据，增加到1000w可能只需要一周的时间
架构的发展模式可以是：
- 单库单表--> 分库 --> 分库分表
- 单库单表--> 分表 --> 分库分表
- 单库单表--> 分库分表
方案设计
-
分片键的选择
这也是一个平衡的过程，需要找到一个可以覆盖crud最多场景的一个字段，可以是主键，可以是用户id，可以是时间，可以是主键+时间
我所在的项目是一个saas系统，所以更多的需要考虑租户端，我们选择了租户的id作为分片键- 优点：租户端的所有操作都会落到一张表中，性能高
- 缺点：其他端的操作就需要全路由所有分表，比如公司内部的运营后台，定时任务，周边系统调用，怎么解决？
- 缺点解决方案
- 改造使用频度很高的字段，我们改造了主键，让主键带上了分片的信息
- 使用映射表，通过映射表关联分片信息，但是需要考虑映射表数据量的问题，我们是只保留了最近一段时间的数据，保证大概率能命中
- 代码改造，让更多的查询场景能够拿到分片信息，这个是需要花时间去梳理业务，去改造
-
平滑发布方案
确认完分片键，那么就需要设计一下平滑发布的问题，分库分表的改造影响的业务会很多，特别是如果是核心表，那么影响面更广，我们采用的方案是双写单读的方案
简单的说，第一期先上线双写，让数据能同时insert，update到分表中，再做一个兜底方案，双写开关，能一键关闭分表的写操作，稳定之后再考虑第二期
第二期再从分表读，同样需要设计兜底方案，需要能一键切回第一期方案中，就是从主表读
具体实现：通过数据源的动态切换实现
读写分离
其实ShardingSphere是有读写分离的功能的，但是我没有用，因为本来也要采用动态数据源了，所以直接自己去实现读写分离，可以实现细粒度的读写分离
使用ShardingSphere遇到的问题和解决方案
。。。
