先聊聊 MongoDB 索引失效最直接的生产后果——它远不止是"查询变慢"那么简单，而是大量请求被迫退化成为全表扫描（COLLSCAN）。在业务高并发场景下，磁盘 IO 与 CPU 会被迅速打满，你所看到的"服务器负载异常飙升"或"Zabbix 监控曲线剧烈抖动"，背后通常就是几十个未命中索引的查询同时在扫描整个集合。尤其对于那些"写入后立即查询"的典型业务（例如插入订单后马上按状态拉取数据），主库会频繁出现锁等待，query 操作耗时延长至 4–5 秒甚至更久——这不是简单的请求超时，而是真实意义上的数据库卡死。
索引失效直接引发慢查询，拖垮整个MongoDB主库
索引失效带来的最直接冲击并非"查询变慢一点点"，而是海量查询集体降级为 COLLSCAN，在高负载下迅速耗尽磁盘 IO 和 CPU 资源。你观察到的"服务器负载突增""Zabbix 曲线剧烈抖动"，绝大多数情况都是几十个没有命中索引的查询同时扫描全表造成的。当业务逻辑中存在"写完立即查"模式（比如插入订单后立刻根据状态进行拉取），主库会频繁进入锁竞争状态，query 操作往往持续 4–5 秒甚至更久——这已经不再是超时问题，而是实实在在的引擎卡死。
复合索引不满足最左前缀，等于没建
假设你创建了 {"orgCode": 1, "fixedStatus": 1, "_id": -1} 这样的复合索引，但实际查询条件只传了 {"fixedStatus": {"$in": [1, 2]}} 或 {"_id": ObjectId("...")}，那么 MongoDB 根本不会走这个索引。它并不会"挑着用"部分字段，而是直接降级为全表扫描。更隐蔽的坑在于：字段顺序写反（例如 {"fixedStatus": 1, "orgCode": 1}）、字段类型不匹配（orgCode 是字符串却传了数字 350119）、或者在 $regex 中使用了不固定的前缀——这些情况都会让整个复合索引形同虚设。就好比给了导航一个残缺的地址，最终只能靠自己摸索路径。
低基数字段单独建索引，反而加重写压力
像 gender、isDeleted 这样只有 2–3 个取值的低基数（Low Cardinality）字段，单独建立索引不但无法有效加速查询（因为选择性太差），反而会拖慢写入性能——每次插入或更新都需要额外维护 B+ 树节点。如果你在 Spring Data 中随手给布尔字段加上 @Indexed 注解，上线后写入吞吐量可能直接下降 20% 以上。真正值得建索引的，应该是那些高频查询且具有高选择性的字段组合，比如 {"tenantId": 1, "createdAt": -1}，而不是孤立的状态位。
索引存在但没生效，explain 才是唯一真相
不要以为建了索引就高枕无忧。务必针对线上典型查询执行 db.collection.explain("executionStats").find({...})，并重点关注三个核心指标：第一，executionStages.stage 必须是 IXSCAN（绝不能是 COLLSCAN）；第二，nReturned 要远小于 totalDocsExamined；第三，executionTimeMillis 必须稳定在毫秒级别。如果 stage 显示为 IXSCAN 但 totalKeysExamined 接近总文档数，说明索引覆盖度不足，需要补充投影字段或重新调整排序逻辑。
真正危险的不是没有建立索引，而是索引建了却不被查询使用——这种"虚假安全感"往往会在流量高峰期集中引爆性能事故。
