分片集群性能瓶颈主因是片键选择不当：范围分片易致写入热点或全集群扫描，哈希分片可均匀写入但牺牲范围查询效率，复合片键需严格遵循字段顺序与索引要求。
选错片键，分片集群很快会变成“单点瓶颈”——不是数据倾斜压垮某个分片，就是范围查询被迫扫全集群。MongoDB 的分片效果不取决于你开了几个分片，而取决于 shard key 是否匹配你的读写模式。
范围分片适合哪些字段？
范围分片依赖字段值的自然顺序，shard key 必须支持范围索引（如 {created_at: 1} 或 {user_id: 1}），且该字段在业务中频繁用于 $gt、$lt、$between 类查询。
- 典型适用场景：按时间查日志（
created_at）、按用户 ID 段导出数据（user_id）、地理位置范围检索（geo_point） - 致命风险：如果写入集中在单调递增字段（如自增
_id或created_at），所有新文档都会落到同一个 chunk，最终堆积在单一分片上 - 必须提前建索引：
db.collection.createIndex({created_at: 1})，否则sh.shardCollection()会报错cannot shard collection without an index on the shard key - chunk 拆分后不可逆：一旦数据按范围划分，MongoDB 不会自动合并相邻小 chunk，需手动
sh.splitAt()或调整chunkSize
哈希分片为什么能缓解热点？
哈希分片对 shard key 值做 64 位哈希（如 {user_id: "hashed"}），把原本连续的值打散成伪随机分布，天然规避写入集中问题。
- 写入均匀性高：即使
user_id是递增整数，哈希后也会均匀落在各分片，适合注册量突增的社交/电商类应用 - 必须用哈希索引：
db.collection.createIndex({user_id: "hashed"})，不能用普通索引替代；否则sh.shardCollection("db.col", {"user_id": "hashed"})会失败 - 范围查询代价高：比如
find({user_id: {$gt: 1000, $lt: 2000}})会被路由到所有分片执行，无法利用哈希的定位优势 - 不支持多字段哈希：
{"a": "hashed", "b": 1}是非法语法，哈希只能作用于单个字段
复合片键能不能兼顾两者？
可以，但必须明确主次——MongoDB 只支持一种分片类型（范围 or 哈希），复合键里最多一个字段设为 "hashed"，其余必须是范围方向（1 或 -1）。
- 常见组合：
{tenant_id: 1, event_time: "hashed"}—— 先按租户隔离，再在租户内哈希打散时间写入热点 - 注意字段顺序：
tenant_id必须在前，否则路由无法先定位租户分片，哈希部分就失去意义 - 不能反过来：
{event_time: "hashed", tenant_id: 1}会导致同一租户数据被拆到多个分片，破坏局部性 - 联合索引必须严格匹配：必须有
db.collection.createIndex({tenant_id: 1, event_time: "hashed"})，缺一不可
最容易被忽略的限制和陷阱
很多团队踩坑不是因为策略选错，而是忽略了 MongoDB 分片的硬约束。
- 片键一旦设定，永远不能修改：
sh.shardCollection()执行后，不能再对集合换shard key，也不能更新片键字段的值（会报cannot modify shard key） - 片键字段必须存在且非空：如果文档缺失该字段，写入会失败，除非你提前设了
default或用partialFilterExpression过滤 - 哈希值不可预测：你无法通过原始值推算哈希后落在哪个分片，调试时得靠
sh.status()查 chunk 分布，或用explain("executionStats")看实际路由路径 - 小集合慎用分片：如果总数据量
