面试速答（先看这里）

**一句话结论：**首先，我们应该尽量避免这种情况的发生，在第一次决定分表的时候，就尽可能根据当前的业务增长量预估一下未来可能需要存储的数据量，并且最好一定的buffer，让这个分表尽可能够，避免出现不够的情况。

60秒标准回答：

有的时候，当我们对数据库做了分库分表后，因为最初的预估数据不够准确，导致后续数据增长很快，表不够了，那么遇到这种情况该怎么办呢？

首先，我们应该尽量避免这种情况的发生，在第一次决定分表的时候，就尽可能根据当前的业务增长量预估一下未来可能需要存储的数据量，并且最好一定的buffer，让这个分表尽可能够，避免出现不够的情况

比如我们线上分表基本都是256、512、1024这样分的

**答题顺序：**结论 → 原理/机制 → 关键流程 → 场景与取舍 → 易错点

回答主线：

**要点1：**有的时候，当我们对数据库做了分库分表后，因为最初的预估数据不够准确，导致后续数据增长很快，表不够了，那么遇到这种情况该怎么办呢？
**要点2：**其次，如果真的后面就不够了，其实也没啥特别好的办法，要么就通用其他的手段来减少数据量，比如我们之前提到过的数据归档等。
**要点3：**那还有，就只剩一条路了，那就是二次分表，即原来的128张不够，那么就需要重新分成256张表。
**要点4：**涉及到分表算法的更新，数据的迁移等。
**要点5：**另外，还有一个值得考虑的，就是如果最开始用的是一致性hash的算法进行分表路由，那么在做二次分表的时候，数据迁移的成本就会低很多，因为影响的节点可能没那么多。

**记忆锚点：**涉及到分表算法 → buffer → 分库分表后 → 用了一致性 → hash

易错提醒：

首先，我们应该尽量避免这种情况的发生，在第一次决定分表的时候，就尽可能根据当前的业务增长量预估一下未来可能需要存储的数据量，并且最好一定的buffer，让这个分表尽可能够，避免出现不够的情况。

加分表达：

其次，如果真的后面就不够了，其实也没啥特别好的办法，要么就通用其他的手段来减少数据量，比如我们之前提到过的数据归档等。
其中最关键的就是如何无损、无缝的做数据迁移了：另外，还有一个值得考虑的，就是如果最开始用的是一致性hash的算法进行分表路由，那么在做二次分表的时候，数据迁移的成本就会低很多，因为影响的节点可能没那么多。
如果提前考虑过的话，用了一致性哈希的话会影响更小一点。

追问准备：