今天咱们来聊聊数据库分库分表那些事儿。为什么要对数据库进行分库分表呢？在数据量达到一定程度之后，查询操作的性能就会变得很差，所以不得不考虑分库分表。那怎么去拆分数据表，用什么样的策略和算法拆分，这是接下来要探讨的重点。

分表的策略常用的有三个，先来说说按照时间点分区。这个方法很实用，适用于订单数据拆分，比如按天分表、按月分表、按年分表。时间越久的数据，被查询到的概率越低，类似于冷热数据的分离。常见的电商或者银行 APP 会提供近三个月、近六个月订单的查询快捷键，其背后大概率就是按照天或者月做了数据表的分区。

再讲讲 ID 取模。以用户表为例，假如用户表有三千万数据，要拆成六个表，每个表五百万，就可以通过用户的 ID 取模将数据分摊到六个表中。查询时也简单，先通过 ID 取模找到所在的表，再执行相关操作。但取模法有个缺点，如果数据量增加需要扩充数据表，之前计算好的取模值就会改变，已有的三千万数据就得重新分片，这会带来大量额外的数据迁移工作，是我们不想面对的。

这时可以考虑一致性哈希。其原理是将整个哈希值的空间组织成一个虚拟的圆环，然后对各个数据表进行哈希，可选择数据表的编号或名称作为关键词进行哈希，这样每个数据表就能确定在哈希环上的位置。存储数据时，只要将数据 key 使用相同的函数哈希，计算出哈希值并确定数据在环上的位置，然后按照算法找到靠近的数据表进行相关数据操作。当数据量增大需要新增数据表时，不用担心像 ID 取模那样的问题，只需计算数据表编号的哈希，对于老数据的迁移也只是影响哈希值比较相近的数据表，迁移这部分数据就行。不过这个算法比较复杂，容易出错，感兴趣的同学可以研究一下，最好还是采用一些中间件来解决。

分表取模这块，个人建议还是按照 ID 取模的方式更好，只要提前算好数据的增量，合理做好规划，比如五年之后需要重新处理数据，到时候再说呗。

好了，今天的内容就到这里，如果您对本期内容有任何疑问，欢迎在评论区留言。谢谢大家！