MongoDB在启用哈希索引后，依靠对索引字段计算哈希值将文档映射到固定数量的哈希桶中。当系统抛出故障码1390并提示哈希索引冲突率高时，说明单个桶内聚集的文档数量已超过合理阈值，导致链表查找变长、写入加锁时间增加。这种现象在高频写入且哈希字段基数偏低的业务中尤为明显，若不及时处理，会逐步演变为查询抖动和主从延迟。
哈希索引的底层结构与冲突成因
哈希索引并不是像B树那样按字段顺序存储，而是通过对索引键执行哈希函数，得到一个整数后再取模映射到预设的桶数目上。MongoDB默认桶数量与索引创建参数相关，当多个不同键计算出相同的桶位置，就会形成冲突。冲突本身并不可怕，哈希表设计之初就允许链式存储，但问题在于如果大量键都落在少数桶里，链式长度暴涨，原本O(1)的查询退化为O(n)扫描。
造成冲突率高的核心原因通常有三方面。其一是索引字段选择不当，例如用性别、状态码这种低基数字段做哈希，天然容易聚集。其二是哈希函数在特定数据分布下产生偏斜，虽然MongoDB使用的哈希算法较为均衡，但若业务键带有明显前缀规律，仍可能放大冲突。其三是文档持续写入使某些桶不断追加，而MongoDB不会自动重新平衡桶分布，时间久了老桶越来越重。
从引擎层看，冲突率高会直接反映在故障码1390上，这是WiredTiger存储引擎在检测到某个哈希索引的冲突指标超过内部警戒线时抛出的通知。它不会立刻中断服务，但会在日志中标记，并可能伴随慢查询增多。理解这一机制，才能避免盲目删索引，而是从源头调整映射关系。
定位高冲突索引与热点桶的实操方法
排查时第一步应确认是哪个集合的哪个索引触发了1390。可以通过数据库日志搜索错误码，结合db.currentOp()观察阻塞会话。更系统的方式是使用collStats命令，在返回结果中查看索引统计信息，重点留意conflictRate或类似指标（不同版本字段名略有差异，部分版本需借助企业版监控）。
如果环境允许，可以写一段脚本遍历索引桶分布。下面示例用聚合管道模拟哈希分桶统计，帮助找出倾斜严重的键区间：
// 假设集合为 orders，哈希索引建在 user_id 上
// 用相同哈希逻辑做分桶，统计各桶文档数
db.orders.aggregate([
{
$project: {
bucket: { $mod: [ { $toInt: { $multiply: [ { $abs: { $indexOfBytes: "salt", { $toString: "$user_id" } } }, 1 ] } }, 16 ] }
}
},
{
$group: { _id: "$bucket", count: { $sum: 1 } }
},
{ $sort: { count: -1 } }
])
// 若前几个 bucket 的 count 远超平均值，说明冲突集中
除了脚本，慢查询日志也是重要线索。开启profiler后，执行时间异常且伴随IXSCAN的语句，很可能正卡在长哈希链上。此时应记录其查询形状，反向推导涉及的索引与字段。对于副本集，还要比对主节点与从节点的冲突率，防止由于回放顺序差异导致从节点更严重。
有些团队会直接重启节点试图消除警告，这并不能解决根本问题，因为哈希桶的分配在索引重建前是稳定的。正确做法是把监控数据保留，作为后续重建索引的评估依据，比如确认每日写入量、峰值文档数，从而决定新索引的桶规模。
降低冲突率的四种有效解决方案
最直接的手段是删除原哈希索引并以更合理的字段重建。若业务必须用哈希分片，可考虑将复合键纳入哈希计算，例如用user_id加created_month组合，打散原本集中的用户。重建时建议在低峰期操作，并利用滚动重建避免锁表：
// 先建新索引
db.orders.createIndex({ user_id: "hashed", created_month: 1 })
// 待同步完成后删旧索引
db.orders.dropIndex("user_id_hashed")
第二种方案是调整哈希索引的粒度。MongoDB部分版本支持在分片集群下通过修改块大小间接影响分布，单机实例则可评估是否改用范围索引。范围索引虽在随机写入时易产生热点块，但不会导致逻辑冲突，对于范围查询也更友好。下表中对比两者差异：
| 维度 | 哈希索引 | 范围索引 |
|---|---|---|
| 等值查询 | 极快，分布均匀时O(1) | 快，但依赖B树深度 |
| 冲突表现 | 高冲突率触发1390 | 无冲突概念，但可能块热点 |
| 范围扫描 | 不支持高效范围 | 原生支持 |
| 写入分布 | 离散写入各桶 | 顺序写入易集中 |
第三类方法是修正数据模型。若发现冲突源于大量空值或默认值，可在应用层生成更具随机性的业务键，比如将UUID作为哈希字段，从根本上提升基数。对于历史数据，可批量补齐缺失字段后再建索引。第四种是针对已发生1390的应急止血：通过db.runCommand({ compact: "orders" })整理碎片，虽不能改桶数，但能缩短物理链，缓解查询延迟，为重建索引争取时间。
最后需要建立长期监控。将冲突率纳入告警规则，当某个索引的桶最大长度超过平均三倍时自动通知。同时在代码评审中规范哈希索引的字段选择，避免再次出现用低基数字段建哈希的情况。只有把机制理解和工程规范结合，才能彻底规避故障码1390反复出现。
MongoDBhash_indexindex_collision修改时间：2026-08-18 05:44:14