微服务启动时自动创建索引易出错，因各服务独立部署、调用时机与参数不一致，导致前台阻塞、重复建索引或漏建排序字段；典型问题包括未设background:true致卡库、误用已废弃ensureIndex()引发索引名混乱、未显式指定name造成MongoDB自动生成冗余索引；必须统一使用createIndex()并强制指定name（格式为{collection}_{field1}_{field2}_..._{directions}）和background:true，复合索引须严格遵循ESR（等值→排序→范围）字段顺序，且索引构建阶段需加分布式锁或升级至MongoDB 4.4+以避免dropIndexes引发的副本集雪崩。
微服务启动时自动创建索引为什么容易出错？
因为每个服务独立部署、独立连接数据库，createIndex() 调用时机和参数不一致，极易触发前台阻塞、重复建索引、或漏建关键排序字段。最典型的问题是：服务 A 启动时没加 background: true，直接卡住整个库；服务 B 用 ensureIndex()（已废弃）导致索引名混乱；服务 C 在同一个集合上反复调用 createIndex() 却没设 name，MongoDB 每次都生成新索引，最终写放大严重。
统一用 createIndex() + 显式 name 和 background
所有微服务必须使用 createIndex()（不是 ensureIndex()），且强制要求两个参数：
-
name必须显式指定，格式统一为{collection}_{field1}_{field2}_..._{directions}，例如orders_userId_status_createdAt_desc，避免 MongoDB 自动生成带随机后缀的名称 -
background必须为true，哪怕在开发环境也禁用前台模式——MongoDB 4.2 及之前版本默认foreground，线上一旦漏配，等于主动停服 - 禁止把 options 拆成多个对象传入，像
db.c.createIndex({a:1}, {unique:true}, {background:true})是无效的，只会生效第一个 options 对象
复合索引字段顺序必须遵循 ESR 原则
微服务间查询模式不同，但索引设计不能各自为政。所有复合索引字段排列必须按 等值（E）→ 排序（S）→ 范围（R） 顺序，否则排序会退化为内存排序，触发 Sort operation used more than the maximum 33554432 bytes of RAM 错误。
比如订单服务常见查询：{userId: "U123", status: "paid"}.sort({amount: -1}).limit(20)，对应索引必须是 {userId: 1, status: 1, amount: -1}，而不是把 amount 放最后——那样 .sort({amount: -1}) 就无法命中索引。
ESR 不是建议，是硬约束：范围字段（如 {$gte: ...}）一旦出现，其右侧所有字段在索引中就失去排序能力，只能逐条过滤。
禁止在索引构建中执行 dropIndexes
这是跨服务协作中最隐蔽的雪崩点。当服务 A 正在后台构建索引时，服务 B 若调用 db.orders.dropIndexes()，在 MongoDB 4.4 以下版本会直接阻塞 oplog 回放，从节点连接池迅速耗尽，整个副本集不可用。
解决方案只有两个：
- 所有服务启动阶段的索引操作，必须加分布式锁（如 Redis lock），确保同一集合的索引变更串行化
- 生产环境强制升级到 MongoDB 4.4+，它支持并发索引构建，从根本上规避该冲突
别指望“大家自觉不同时操作”，微服务数量一多，时间差几毫秒就可能撞上。
