分库分表一定是，数据量和并发大到所有招数都不好使了，才拿出来的最后一招。
如何规划分库分表
在考虑到底是分库还是分表之前，先明确一个原则，那就是能不拆就不拆，能少拆不多拆。原因也很简单，把数据拆分得越散，开发和维护起来就越麻烦，系统出问题的概率就越大。
解决查询慢——分表
解决高并发——分库
一般情况下，都需要同时做分库分表，这时候分多少个库，多少张表，分别用预估的并发量和数据量来计算就可以了。
不建议在方案中考虑二次扩容的问题，也就是考虑未来的数据量（现在技术和业务变化这么快，等真正到了那个时候，业务早就变了，可能新的技术也出来了，越简单的设计可靠性越高）。
如何选择 Sharding Key
选择一个合适的列或者说是属性，作为分表的依据，这个属性一般称为 Sharding Key。查询条件中必须带上这个 Sharding Key，这样程序才知道每次该访问哪个库和表。
选择 Sharding Key 的时候，一定要能兼容业务最常用的查询条件，让查询尽量落在一个分片中，分片之后无法兼容的查询，可以把数据同步到其他存储中去，来解决这个问题。
我们常用三种分片算法，范围分片容易产生热点问题，但对查询更友好，适合适合并发量不大的场景；哈希分片比较容易把数据和查询均匀地分布到所有分片中；查表法更灵活，但性能稍差。
PS：对于订单表进行分库分表，一般按照用户 ID 作为 Sharding Key，采用哈希分片算法来均匀分布用户订单数据。为了能支持按订单号查询的需求，需要把用户 ID 的后几位放到订单号中去。
网友评论