布尔值和低基数枚举值不能用作分片键，因其导致chunk分布失败、数据倾斜及均衡器失效；应选用高基数、非单调、写入分散的字段如hashed _id或合理组合业务字段。
布尔值当分片键：只有 true/false 两个值，MongoDB 直接“卡住”
不行。布尔值作为分片键会触发 chunk distribution failure —— MongoDB 无法生成足够多的数据块（chunk），因为分片键值域只有两个离散点，根本划不出有意义的范围区间。默认 chunkSize 是 128 MB，但哪怕你手动 split，也最多得到两个块（{ status: true } 和 { status: false }），所有写入必然集中到这两个块所在的分片上，彻底失去分片意义。
- 即使集合有千万级文档，只要分片键是
status: true/false，所有true文档全挤在同一个 chunk、同一个分片里 -
sh.status()会显示 chunk 数极少（常为 1–2），且balancer完全不工作——没得可均衡 - 哈希分片（
{ status: "hashed" }）也不能救：哈希后仍是高度聚集的分布，因为输入基数太低，哈希输出碰撞率极高
枚举值做分片键：要看枚举项数量，少于 10 个基本等于自废武功
可以“语法上”用，但实际效果等同于弱分片键。比如 type: ["user", "order", "log"] 这类 3 值枚举，MongoDB 能建分片，但很快就会出现严重倾斜——某个类型（如 "log"）写入量暴增，对应 chunk 迅速膨胀、无法迁移，最终该分片磁盘和 CPU 全拉满，其他分片却空转。
- 高基数 ≠ 高写入分散性：就算你有 50 个枚举值，但如果 90% 写入都落在其中 2 个值上（例如
"pending"和"success"），一样会热分片 - 查询收益极低：按枚举字段查（
db.col.find({ type: "user" })）能路由到单一分片，但代价是写入完全不可扩展 - 别指望加索引补救：
createIndex({ type: 1, created_at: -1 })对分片有效性零帮助——分片键本身决定数据物理分布，索引只管查找路径
真正可用的替代方案：必须引入高基数、非单调、写入分散的字段
不是“换个字段就行”，而是要重设计数据模型。核心原则：分片键值必须随时间/业务自然发散，不能靠人工归类。
- 优先考虑
_id（如果用 ObjectId）：天然高基数、写入均匀，但注意它时间戳前缀可能导致写热点（新文档总往同一分片追加）——可改用hashed模式：sh.shardCollection("db.col", { _id: "hashed" }) - 组合真实业务维度：比如
{ region: 1, user_id: 1 }，前提是region至少有几十个有效取值，且用户在各 region 分布相对均匀 - 绝对避开时间类单调字段：如
created_at、timestamp单独作分片键，会导致所有新数据写进同一个 chunk，永远无法自动分裂（MongoDB 不会为“未来时间”预分配 chunk）
已经用了布尔/枚举键？别幻想在线改，备份恢复是唯一路径
MongoDB 5.0+ 虽支持 reshardCollection，但它只允许在原分片键基础上“加字段后缀”，比如从 { active: 1 } 扩展成 { active: 1, user_id: 1 } —— 但如果你的原始键只有两个值，加了也白加，倾斜照旧。真要换，只能停写、导出、重建集合、重分片、重导入。
-
mongodump --uri="mongodb://..." --db=mydb --collection=col导出 - 删掉旧集合，用新分片键创建：
sh.shardCollection("mydb.col", { user_id: 1, timestamp: 1 }) - 导入前务必
sh.splitAt("mydb.col", { user_id: ObjectId(...) })预分割，否则首次导入会卡在单一分片 - 这个过程在 TB 级数据上可能持续数小时，期间服务不可写——这就是当初选错键的代价
