分片数量计算器

分片数公式：片数 = 数据总量 ÷ 单片目标容量，再取整到「路由友好」的值。单片容量的经验值：MySQL 单表 500-1000 万行（或 200GB）内查询健康，超过后 B+ 树深度增加、DDL 锁表时间失控；Elasticsearch 单片（shard）20-50GB 是官方甜点（恢复速度与查询并行度的平衡）；Kafka 分区数决定消费并行度上限。分片数拍脑袋的后果：分少了两年后二次拆分（迁移痛苦 ×10），分多了元数据与小文件开销反噬（ES 每片占内存，千片集群 master 直接崩）。

取整策略大有讲究：① 2 的幂（8/16/32）——一致性哈希与位运算路由（hash & (n-1)）最干净，扩容翻倍时数据迁移量可控；② 预留增长——按 2-3 年预测量计算，分片数一次到位（改分片数 = 全量数据重分布）；③ 与副本解耦——物理实例数 = 逻辑分片 × 副本因子，别混为一谈。一致性哈希（ketama）能把扩容的迁移量从 100% 降到 1/N——Redis Cluster 的 16384 个 slot 就是「固定槽位 + 灵活映射」的折中设计，槽不动、节点动。

分片的动机是三堵单机墙：容量墙——单机磁盘装不下（2TB 级单表备份窗口就已失控）；写入墙——单机写入 TPS 有上限，索引越多写入越慢；连接墙——单机可承载的连接与并发查询有限。读压力可以靠只读副本缓解，这三堵墙只能靠水平拆分。判断该分片的信号不是「现在很慢」，而是「按增速，18 个月后撞墙」。

分片键选择是三原则的权衡：高基数（区分度大，用户 ID 优于省份）、分布均匀（避免 20% 的键扛 80% 的流量）、查询主路径命中（80% 的查询能带分片键定位单片）。经典反例：订单系统按下单时间分片——新订单全写最新的片，热点集中且无法并行。补救方案是组合键（用户 ID + 时间）或写入侧加散列后缀。

路由机制的三种主流：① 取模/位运算（hash & (n−1)，n 取 2 的幂）——最简单，扩容翻倍时只需迁移一半数据；② 一致性哈希——扩容迁移量降到 1/N，但路由层要维护哈希环；③ 固定槽位（Redis Cluster 16384 槽）——槽数恒定、槽到节点的映射可变，迁移以槽为单位，兼顾两者优点。选型默认顺序：能用 2 的幂就别引入额外复杂度。

分片过多的隐性成本常被低估：每个分片都有元数据开销（ES 每片占用 master 内存，千片集群 master 直接崩）；小查询被放大——一次跨 10 片的查询，总耗时取决于最慢那片（尾延迟放大）；运维复杂度随片数线性上升（备份、监控、扩容的单元数）。片数的目标是「三年够用」，不是「一次到位管十年」。

扩容与迁移的纪律：① 数据量预测先行——用 容量增长计算器 按复利外推三年；② 扩容方式在设计期就定死——翻倍拆分（迁移 50%）还是槽位迁移（迁移 1/N），迁移期间的双写与校验方案提前演练；③ 物理拓扑解耦——逻辑片数与物理节点通过 副本因子计算器 联合规划，副本是可用性问题，分片是容量问题，别混着算。