分库分表的考虑点

现在很多项目动不动就分库分表，其实分库分表应该是非常谨慎的操作，如果是为了存放大量数据，就选择分库分表，这种行为是非常草率的。

这里先不提海量数据的解决方案，单论分库分表前应该做什么考虑。

1、首先从业务层数据量估计，是否有分库分表的必要，因为一旦分库分表无论是成本还是技术难度都会上升，尤其是多维度查询时，往往伴随如冗余双写或者是NOSQL等策略。比如冗余双写，就伴随着一致性问题，锁问题，以及事务问题等。
2、分库分表的策略，要尽可能避免IO热点：也就是数据库的操作集中在某几个库表。这里算法比较多， 仁者见仁智者见智，并不是单纯选择字段做PartitionKey然后hash取模就可以的
3、如果数据量增长迅速，要建表之初就要考虑后期数据迁移的问题，尽可能做到旧数据不迁移：比如在一个短链项目中，短链码我们采用库表位的形式，那么后期增加库就不需要迁移数据
4、业务流量模型，也就是这部分表的查看操作并不是很频繁，比如流量包，很少会被查询。对于这部分数据，其实是以存储为主，这种数据就可以不用“太花里胡哨”的分片策略。
5、多维度查询的情况，尽可能避免全库全表的检索，这是非常耗费性能的。通常解决这个问题采用空间换时间的概念。
6、主键id冲突的问题，比如一个Link逻辑表，把他分成了4库共12张表，你如果简单的采用自增id，那么是非常不理智的行为，要保证id不同，这是一个约定俗成的规则（哪怕这个id不是主键，不参与CUID）。同时也要避免自增id暴露商业机密。

以上六点只是我个人在项目中的一些看法，欢迎其他人进行补充或者纠正。

所以，分库分表是一个非常慎重的事情