分片集群里所有决策，没有比**片键（shard key）**更重要的了。片键决定了数据怎么分布到各个 shard、写入会不会形成热点、查询能不能定向到单个 shard。更关键的是，片键一旦选定极难更改（虽然新版有 reshardCollection，但仍是大工程）。片键选错，整个集群会数据倾斜、写入热点、查询全广播，且很难回头。
这一篇是分片阶段的核心，讲清楚选片键要同时满足的三个目标，以及常见片键各自的取舍。
先把机制边界说清楚
片键是分片集合里用来决定「这条数据存到哪个 shard」的字段（或字段组合）。MongoDB 按片键的值，把数据划分成一个个 chunk（块），每个 chunk 是一段连续的片键范围，分配到某个 shard。balancer 会在 shard 间迁移 chunk 保持均衡。
所以片键直接决定了：
- 数据分布：片键值越分散，数据越均匀；片键值越集中，数据越倾斜。
- 写入热点：片键单调递增时，新数据总落在「最大值」那个 chunk（通常在最后一个 shard），形成热点。
- 查询路由：查询带片键前缀时，mongos 能定向到单个 shard；不带片键则广播到所有 shard。
片键的三个目标，就是从这三个维度提出的。
片键的三个目标
① 基数高（Cardinality）。片键的取值要足够多样。如果片键只有几个值（比如 status 只有 active/inactive），数据无法有效分散，会集中到少数 chunk 和 shard。基数越高，越能细粒度分散。ObjectId、userId 这类高基数字段合格；status、type 这类低基数字段绝对不能用。
② 写分散（Write Distribution）。写入要均匀打到各个 shard。如果片键是单调递增的（时间戳、自增 ID、ObjectId 的范围分片），所有新数据都落在最大值那个 chunk，写入集中到一个 shard，形成热点------这个 shard 扛着全部写入压力，其他 shard 闲置。哈希分片是解决单调递增热点的常用手段（下一篇展开）。
③ 查询定向（Targeted Query）。高频查询要能带上片键，这样 mongos 能定向到单个 shard。如果高频查询不带片键，每次都广播到所有 shard（scatter-gather），放大负载。所以片键应该是业务高频查询会带上的字段。
这三个目标往往互相冲突：基数高且写分散的键（如随机 ID）通常查询难定向；查询能定向的键（如时间范围）往往单调递增会热点。选片键就是在这三者间找平衡。
常见片键的取舍
把常见片键按三个目标评估：
时间戳/自增 ID（范围分片）。基数高，范围查询能定向，但写入全部集中到最后一个 shard，形成严重热点。除非配合别的字段，否则不适合单独做片键。
ObjectId 哈希分片。基数高、写均匀分散（哈希打散了单调性），是最通用的选择。代价是查询很难定向（按 ObjectId 查的场景少），多走广播。适合「没有明显查询定向需求、只求分散」的场景。
userId 范围分片。基数高（用户多）、按用户查询能定向、写较分散（不同用户的数据分散）。适合以用户为维度的业务（用户内容、用户订单）。但单个大用户的数据会集中在一个 chunk，形成局部热点。
复合片键 {userId, 时间}（范围分片）。这是常被推荐的组合：userId 保证查询定向和分散，时间作为第二字段让单用户的数据按时间聚集（方便按时间范围查）。兼顾了三个目标，适合多数用户维度业务。
粗粒度键（如 status、type）。基数极低，数据完全无法分散，会形成 jumbo chunk（无法迁移的超大块）。绝对不能用作片键。
怎么选：按业务查询模式出发
选片键的正确姿势是从业务的高频查询反推，而不是从字段挑：
- 列出业务最高频的查询（比如「按 userId 查用户订单」「按时间范围查日志」）。
- 找出这些查询都会带上的字段------它就是片键的候选。
- 评估这个字段的基数（够不够分散）和写入模式（会不会热点）。
- 如果单调递增会热点，考虑加哈希或复合字段。
- 如果单字段无法兼顾，用复合片键。
核心判断：片键应该是业务查询的「天然维度」。用户维度业务用 userId，日志业务用时间（配合哈希或机器 ID 防热点），内容业务用内容 ID。片键和查询模式对齐，查询才能定向，集群才能高效。
片键的不可逆性
强调一遍：片键极难更改 。老版本改片键几乎不可能（要重建集合）；新版有 reshardCollection，但要重新分布所有数据，是个耗时且高风险的大操作。所以片键必须在上线前仔细设计，一旦数据量大了，错了就是长期的痛。
评估片键时，要模拟未来的数据增长和访问模式：一年后数据量翻十倍，这个片键还撑得住吗？查询模式会变吗？宁可上线前多花时间设计，也不要带着错误的片键上线。
判断框架
- 片键三个目标：基数高、写分散、查询定向，三者难兼顾要取舍。
- 从高频查询反推片键，而不是随便挑字段。
- 单调递增键（时间戳/自增）单独用会写热点，配哈希或复合字段。
- 低基数键（status/type）绝对不能用，会形成 jumbo chunk。
- 复合片键 {粗维度, 细维度} 是兼顾三者的常用形态。
- 片键几乎改不了，上线前模拟未来增长仔细设计。
这篇真正要守住的边界：片键设计
把它放到线上看，关键不是名词，而是：片键决定数据分布、写入热点和查询路由。
做架构评审时，一旦片键选错，后续迁移和改造成本极高。 分片和治理问题不能只看节点数量，要看片键、chunk、路由命中、热点和恢复演练。
现场复盘里的三问
评审追问一：这个设计等到数据增长后会先暴露什么问题？
片键决定数据分布、写入热点和查询路由。
评审追问二：什么情况下这个结论会失效？
一旦片键选错，后续迁移和改造成本极高。
评审追问三：用哪些证据确认它真的成立？
用基数、增长趋势、查询条件、写入分布和 chunk 分布验证。
下一篇讲范围分片 vs 哈希分片的取舍。
关于十三Tech
我是十三，长期关注服务端架构、数据库、中间件和 AI 工程实践。
我相信好的技术文章应该能回到真实系统里，帮人少踩一次坑。
关于十三Tech
All in AI Agent 方向的架构师，专注 AI 工程实践。
相信 AI 是程序员的最佳搭档，帮助每一位开发者驾驭 AI。
公众号搜索「十三Tech」