_id不能直接作哈希分片键，因其objectid前4字节为单调递增时间戳，导致哈希后新写入仍集中于少量分片，引发局部热点；须选用高基数、无时序规律字段，或转字符串哈希（不推荐）。
为什么 _id 不能直接当哈希分片键用
MongoDB 的哈希分片要求分片键必须是单字段、不可变、且值分布足够离散。虽然 _id 默认是 ObjectId，但它的时间戳前缀导致新写入集中在少数 chunk（比如最近一小时的 ObjectId 都以相似字节开头），哈希后仍可能局部热点——不是“不够随机”，而是哈希函数作用对象错了：MongoDB 对分片键值做哈希，不是对整个文档哈希。
- ObjectId 本身含时间戳 + 机器标识 + 进程 ID + 自增计数器，前 4 字节单调递增，直接
{ _id: "hashed" }分片后，新写入仍扎堆在少量分片上 - 真正有效的哈希分片键应是业务无关、高基数、无明显时序/语义规律的字段，比如用户手机号的哈希、订单号的后 8 位、或显式生成的
shard_key字段 - 如果硬要用
_id，得先把它转成字符串再哈希（但不推荐：浪费存储、破坏 ObjectId 语义、索引效率略降）
sh.addShardKey() 执行前必须确认的三件事
哈希分片不是加个索引就完事，它会触发全量数据重分布，过程中集群读写性能下降、主从延迟拉高，甚至阻塞某些操作。没准备就跑命令，容易卡在迁移阶段或触发 chunk 拆分风暴。
- 目标集合必须已有非空数据，且已建好对应字段的普通升序索引（哈希分片键索引 MongoDB 会自动建，但前提是你得先有基础索引）
- 确保所有分片磁盘空间充足，且
sh.status()显示各分片状态为OK，没有draining或recovering状态 - 关闭应用层的批量写入重试逻辑（尤其使用
retryWrites: true的驱动），否则迁移中报InterruptedDueToReplStateChange错误会不断重试，拖慢进度
哈希分片 vs 范围分片：写入打散效果差在哪
哈希分片把键值哈希后映射到 0–2^64 区间，再按 chunk 均匀切分，所以相同前缀的键大概率落到不同分片；而范围分片按原始值排序切分，哪怕加了随机后缀，只要前缀集中（比如 "user_123_" + randomString(8)），仍可能让一批写入落在同一 chunk。
- 哈希分片写入天然打散，但丧失范围查询能力：
{ created_at: { $gt: ISODate("...") } }无法高效路由，必须广播到所有分片 - 范围分片支持高效时间范围扫描，但写入热点难避免——除非你用复合键如
{ shard_prefix: 1, created_at: 1 }并保证shard_prefix基数够高 - 混合策略更常见：用哈希分片键支撑高并发写入，另建 TTL 索引或按天分表处理冷热分离，而不是指望一个分片键解决所有问题
哈希分片后查不到数据？检查这四个地方
哈希分片启用后，最常被忽略的是查询条件没带分片键——MongoDB 不允许在未指定分片键的前提下执行点查或范围查，否则报 error: { "ok": 0, "errmsg": "Query not supported on sharded collection without shard key", ... }，不是数据丢了，是路由失败。
- 所有
find()、updateOne()、deleteOne()必须包含分片键等值匹配，比如分片键是{ user_hash: "hashed" }，那查询必须带{ user_hash: "abc123" } - 聚合管道里如果用了
$lookup关联非分片集合，没问题；但若关联另一个分片集合，且没传分片键，同样会路由失败 - 使用
explain("executionStats")看executionStages.shards字段，若只显示 1 个分片，说明查询被路由到了错误位置——大概率是分片键值类型不一致（比如存的是字符串，查的是 ObjectId） - 驱动版本太老（如 Node.js driver hint: { user_hash: 1 }
sh.status() 的 chunk 分布和 db.printShardingStatus() 的迁移队列，比看监控图表更直接。很多人调完就走，结果发现 70% 写入还在两个分片上——那多半是分片键基数不够，或者写入模式本身就有强聚集性，哈希也救不了。
