分库分表的数量为什么一般选择 2 的幂？

面试考察点

1. 基础掌握度：面试官想知道你是否真的做过分库分表，还是只是看过几篇博客。能不能从路由算法层面讲清楚，是个分水岭。

2. 原理理解深度：能否说清楚 "2 的幂" 和 "取模运算"、"位运算" 的关系。这块其实和 HashMap 容量为什么是 2 的幂是同一个问题，能联系起来就加分。

3. 生产实践意识：扩容这个事是真刀真枪的——分片数选错了，扩容时数据迁移能让你怀疑人生。面试官想看你是否理解工程层面的取舍。

核心答案

先给结论：分库分表数量选 2 的幂（2、4、8、16、32...），主要基于下面三个原因：

下面挨个展开。

深度解析

一、位运算代替取模：性能更优

这是最底层的原因。

当 n 是 2 的幂时（n = 2^k），有一个数学恒等式：

hash(key) % n == hash(key) & (n - 1)

举个例子，n = 8，二进制是 1000，n-1 = 7，二进制是 0111。

任何数对 8 取模，结果其实只看低 3 位；用位与 & 0111 也是只保留低 3 位，结果完全一样。

但位与运算在 CPU 上比取模运算快得多，取模在底层是除法，CPU 周期数是位运算的十几倍。高并发路由下，这点差距会被放大。

// 路由分片号的两种写法，等价但性能不同
int shard1 = hash(key) % n;        // 取模运算
int shard2 = hash(key) & (n - 1);  // 位与运算（要求 n 是 2 的幂）

这个套路熟悉不熟悉？HashMap 的 tableSizeFor() 强制把容量扩到 2 的幂，原因一模一样。能把这两件事联系起来，面试官就知道你是真懂。

二、扩容时数据迁移量最小：这才是工程层面的杀手锏

很多同学只答 "方便扩容"，但说不出具体怎么个方便法。我详细画一下。

假设原来 4 个分片，扩到 8 个分片：

上图这张迁移图是这道题的精髓，看不懂没关系，听我讲：

• 扩容前 4 个分片，路由用 hash & 011（也就是 & 3），只看低 2 位
• 扩容后 8 个分片，路由用 hash & 111（也就是 & 7），看低 3 位
• 多了一位高位，原来的每个分片数据按这一位是 0 还是 1，刚好对半劈开

具体来说：

• 分片 0 的数据，扩容后按第 3 位（值为 4）拆开：第 3 位为 0 的留在分片 0，第 3 位为 1 的迁到分片 4
• 分片 1 同理：一半留在分片 1，一半迁到分片 5
• 分片 2、3 以此类推

最终结果：每个老分片只迁移 50% 数据到对应的新分片，迁移总量正好是总数据量的一半。这是数学上的最优解。

如果是非 2 的幂，比如 3 个分片扩到 6 个分片，迁移路径会非常混乱——几乎没有一个老分片能 "干净地" 拆成两个新分片，所有数据都得重新路由，迁移量接近 100%。这种扩容在实际生产中几乎不可行。

三、扩容前后路由对比（代码示例）

public class ShardingRouter {

    // 扩容前：4 个分片
    public int routeBefore(int hash) {
        return hash & 0b011;
    }

    // 扩容后：8 个分片
    public int routeAfter(int hash) {
        return hash & 0b111;
    }

    /**
     * 扩容迁移判断：判断原数据是否需要迁移到新分片
     * 老分片 oldShard 的数据，如果 hash 的最高位为 1，
     * 就迁移到 oldShard + oldN（即扩容前分片数）
     */
    public boolean needMigrate(int hash, int oldShard, int oldN) {
        int newShard = hash & (oldN * 2 - 1);
        return newShard != oldShard;
    }
}

看 needMigrate 这个方法，2 的幂的真正威力就体现出来了：判断一条数据要不要迁移、迁到哪，只看一个 bit 就够了。这就是 "扩容友好" 的本质。

四、与其他系统设计的呼应

能想到这一层，说明你举一反三能力强。下面这些场景都是同一个套路：

• HashMap：容量必须是 2 的幂，tableSizeFor() 强制保证这一点，路由就是 (n-1) & hash
• Redis Cluster：哈希槽数 16384 = 2^14（不过 Redis 用的是 CRC16 取模而不是位与，选 2^14 更多是为了心跳包位图压缩，原因和 HashMap 不完全一样，但 "工程上偏爱 2 的幂" 这个倾向是一致的）

工程上有个不成文的说法："只要涉及分片，优先考虑 2 的幂"。

面试高频追问

1. 追问一：分片数不是 2 的幂行不行？

   行，没人拦你。但你要承担两个代价：路由用不了位与优化（性能略差），扩容迁移量爆炸（这是大问题）。如果是范围分片或者一致性哈希，对 2 的幂的要求就没那么强。

2. 追问二：分库和分表的数量怎么配合？

   常见做法是 库数 × 表数 为 2 的幂。比如 4 库 8 表 = 32 = 2^5。这样路由时可以统一用位与，不用分两步算库号和表号。ShardingSphere 这类中间件支持通过 Groovy 行表达式（比如 ${id % 8} 或 ${id & 7}）灵活配置分片规则。

3. 追问三：一致性哈希和 2 的幂是什么关系？

   一致性哈希本身不要求 2 的幂（它的环空间是 0 ~ 2^32-1），它的扩容优势来自于 "环形空间 + 顺时针路由"，和 2 的幂没关系。但工程实现里（比如一些虚拟槽设计）经常用 2 的幂，主要是位运算友好、迁移路径清晰。

常见面试变体

• "分库分表扩容怎么做？"
• "为什么 HashMap 的容量要选 2 的幂？"
• "一致性哈希是怎么扩容的？"
• "ShardingSphere 的分片算法你了解几个？"

记忆口诀

"位与快、扩容轻、工程统一"——位运算替代取模快，扩容只迁一半数据轻量，与 HashMap 等设计统一复用工程经验。

总结

一句话：分库分表选 2 的幂，本质是为了 路由用位与（快）、扩容迁一半（轻）。能把这两条讲到代码层面，再补一句 "HashMap 容量也是这个套路"，面试官基本就满意了。