复合哈希分片键需按业务流量设计，{company_id: "hashed", create_time: 1}因company_id区分度低且create_time无法支持范围扫描而失败；有效结构应高频字段前置、高区分度字段哈希后置，并用analyzeShardKey验证。
复合哈希分片键不是“加个"hashed"就能均匀分布”，关键在于字段顺序、区分度和查询模式是否匹配。直接套用{company_id: "hashed", create_time: 1}大概率导致数据倾斜和广播查询，必须按业务真实流量设计。
为什么{company_id: "hashed", create_time: 1}在SaaS场景下会失败
这个组合看似兼顾了租户隔离和时间范围查询，但实际踩中两个硬伤：
-
company_id在多租户系统中重复度极高（比如几千个客户共用几十个company_id），哈希后仍无法打散，chunk 分布严重不均 -
create_time放在哈希字段之后，MongoDB 无法利用它做范围扫描——所有{$gt: ISODate("2026-01-01")}查询都会广播到全部分片 - 如果同时存在
{"company_id": 1}索引，mongos可能误选该索引，触发全量路由
怎么构造真正有效的复合分片键
核心原则：高频查询字段前置（支持路由+范围扫描），高区分度字段哈希后置（保障单前缀内写入均匀）。
- 推荐结构如
{region: 1, user_id: "hashed"}：region必须是业务真实存在、非单调的字段（不能是_id或时间戳），用于路由和范围过滤；user_id需为单值、非数组、非浮点（或≤2⁵³） - 避免把
create_time放第二位——若业务强依赖时间范围，应将其前置，再补一个高区分度哈希字段，例如{create_time: 1, trace_id: "hashed"} - 哈希字段不能是复合值（如嵌套文档或数组），否则会报错
Cannot use hashed index on an array field
必须用analyzeShardKey验证，别靠经验拍脑袋
MongoDB 7.0 的analyzeShardKey是唯一能基于真实数据采样预判分片效果的工具，执行后重点看三项：
-
imbalancedChunks>5%：说明即使加了哈希，数据仍在某些分片上堆积 -
broadcastOperations值高：代表你设计的前缀字段没覆盖常见查询条件（比如漏了region或create_time等过滤项） -
estimatedChunkCount超过 1000：前缀粒度太细，会导致迁移压力大、元数据膨胀 - 命令示例：
db.visitor.analyzeShardKey({region: 1, user_id: "hashed"}, {sampleSize: 100000})
预拆分和写入策略比哈希算法本身更重要
MongoDB 7.0 的"hashed"底层固定用 MD5（取低 64 位），无法替换或优化。所谓“高效”，其实是靠组合动作规避瓶颈：
- 空集合必须预拆分：
sh.shardCollection("db.col", {region: 1, user_id: "hashed"}, {numInitialChunks: 256})，否则所有初始写入挤在一个 chunk - 写入时禁用有序模式：
db.col.bulkWrite(ops, {ordered: false})，否则默认串行发往单个分片 - 若原始 ID 单调（如自增订单号），仅哈希不够稳妥，建议改造分片键加入随机性，例如
{ts: ISODate(), rand: Math.random()}再对rand哈希 - 检查
sh.status()中各分片的 chunk 数量是否接近——某 shard chunk 明显偏少，说明数据根本没打散
最容易被忽略的一点：分片键一旦选定，重定义成本极高；而analyzeShardKey的采样结果只反映当前数据分布，如果业务写入模式突变（比如新增一个高频查询字段），原有分片键可能瞬间失效。上线前务必用真实流量压测，而不是只看采样报告。
