自增ID作分片键必然导致单点写入，因范围分片将新文档全路由至最大值所在chunk，该chunk固定驻留于单一分片且均衡器不主动拆分或迁移；需改用高基数字段（如UUID）配合哈希分片或复合分片键来分散写压力。
_id 字段用自增整数（如计数器生成）作分片键，必然导致写热点——新文档全挤在最大值区间，只往一个分片写，其他分片闲置。这不是配置问题，是范围分片的底层机制决定的。
为什么自增ID会堵死一个分片？
MongoDB 范围分片按 _id 值切 chunk，比如划分成 [1, 1000), [1000, 2000), [2000, ∞)。所有新插入的自增 ID 都落在最后一个区间，而这个区间默认驻留在某个分片上。均衡器不会主动拆它、也不会迁移它——除非你手动干预。
- 现象：用
sh.status()看到某分片 chunk 数极少但数据量占 80%+ - 根本原因：MongoDB 不认为“持续追加”是不均衡，它默认这是合理行为
- 补救无效：仅
sh.splitAt()只切逻辑块，不移动数据；不配sh.moveChunk()就等于没动
改用随机 ObjectId 或 UUID 真能分散吗？
能，但必须作为分片键本身参与路由，而不是只当文档主键。
-
ObjectId默认是时间前缀 + 随机后缀，本身有部分单调性；单独用作分片键（{ _id: 1 }）仍可能热点 -
UUID（v4）完全随机，高基数，天然适合范围或哈希分片 - 关键操作：
- 必须显式设为分片键：
sh.shardCollection("db.col", { "uuid_field": "hashed" }) - 不能只靠客户端生成随机
_id却用timestamp当分片键——路由还是按后者走 -
ObjectId若想直接用，推荐哈希：{ _id: "hashed" }，MongoDB 自动处理，无需预建索引
- 必须显式设为分片键：
哈希分片后，点查和范围查询表现差异极大
- 点查（
find({ uuid_field: "xxx" })）变快：mongos 精准路由到 1 个分片 - 范围查（
find({ uuid_field: { $gt: "a", $lt: "z" } })）变慢：必须广播到所有分片，网络开销翻倍，聚合失效 -
$min/$max、sort()在该字段上基本不可用
容易被忽略的真实负载陷阱
sh.status() 显示 chunk 分布均匀 ≠ 实际负载均衡。某分片可能 chunk 数正常，但因以下原因成为热点：
- 该分片上缺失关键查询索引，导致大量文档扫描
- 应用层高频读取某几个
uuid_field值（比如固定用户 ID），反复打在同一分片 -
mongos缓存了错误的路由信息，或配置服务器元数据延迟
必须结合 db.currentOp() 查活跃操作来源，用 mongostat 看各分片 netIn/conn，而不是只盯 chunk 数量。
