水平拆分与分片键：一次选择，决定后半生
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 4 · 分库分表 · 第 24/49 篇 · 🚧 占位待学
上一篇：《垂直拆分：按业务与按读写特征切》
下一篇：《全局唯一 ID：雪花算法与时钟回拨》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 4 · 单元 4.3
一、本文要解决的问题
单表 5 亿行，水平拆成 16 库 64 表——按什么拆？分片键的选择是分库分表里最重的一个决定：它决定数据分布是否均匀、大多数查询能否落在单分片、将来扩容痛不痛苦。选错了，后面每一步都在还债。
二、知识点清单
- 三种路由方式：range（按范围，好扩容但热点集中）、hash（均匀但扩容痛）、查找表（灵活但多一跳）
- 分片键选择原则：最高频查询维度优先（C 端按 user_id）、避免数据倾斜（大 V / 大商户）
- 基因法：把 user_id 的分片基因编进订单号，让「按用户查」与「按订单号查」都路由到同一分片——多维度路由的经典解
- 非分片键查询的代价：全分片广播（聚合 / 分页）、异构索引表（binlog 同步另建一张按订单号分片的表）
- 分片数怎么定：按三年容量倒推，一次到位（64 / 128），减少未来扩容次数
三、动手实验（学习时必须真跑）
- 设计「订单表按 user_id hash 16 库 64 表」方案（分片算法：hash(user_id) % 64）
- 灌 1000 万条测试数据（含模拟大用户），统计各分片行数验证均匀度；构造倾斜数据观察倾斜后果
- 实现基因法订单号生成（user_id 基因嵌入），验证两个维度都单分片命中
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。