事务内查询慢的根源是索引未覆盖，导致docsExamined远大于nreturned；覆盖索引可避免回表、缩短锁持有时间、防止内存排序，需在事务上下文中用explain验证IXSCAN且totalDocsExamined为0。
事务内查询慢，不是因为事务本身拖慢了，而是事务里执行的查询没走对索引——尤其当 find 或 update 带多个条件、还要排序分页时，docsExamined 远大于 nreturned，说明索引没覆盖全，还得回表读文档。
事务中为什么覆盖索引特别关键
事务要求原子性与一致性，所有操作必须在单次会话中完成。一旦事务内某个查询触发大量文档扫描（比如 docsExamined: 12480 但 nreturned: 5），不仅拖慢当前事务，还会延长锁持有时间，阻塞其他写入。而覆盖索引能让 MongoDB 直接从索引结构返回全部所需字段，跳过磁盘读文档这一步。
- 事务不改变索引行为，但放大低效索引的代价：一次慢查 = 更长的写锁 + 更高的
numYields - 只有当
explain("executionStats")中的executionStages.stage显示IXSCAN且docsExamined === 0，才算真正“覆盖” - 复合索引字段顺序必须严格匹配查询条件 + 投影字段：比如
find({a: 1, b: 2}, {a: 1, b: 1, c: 1})要想覆盖，索引得是{a: 1, b: 1, c: 1}，不能是{a: 1, c: 1, b: 1}
如何验证事务里的查询是否命中覆盖索引
别只在 shell 里跑 explain()，要在事务上下文中测。直接用 session.startTransaction() 包一层再执行，否则看到的可能是非事务路径的执行计划。
- 正确姿势：
session.startTransaction(); db.orders.find({status: "paid", userId: "u123"}, {orderId: 1, amount: 1, _id: 0}).explain("executionStats"); session.abortTransaction(); - 关键看输出里是否有
"totalDocsExamined" : 0和"executionStages.stage" : "IXSCAN"同时成立 - 如果出现
"stage" : "FETCH"，说明索引没覆盖，MongoDB 还得根据索引指针去磁盘捞完整文档——事务里这是高危信号
多级索引设计要配合事务的读写模式
事务常用于“读-改-写”闭环，比如扣库存+记日志+更新状态。这时候索引不能只考虑单个查询，得兼顾多个操作共用同一组字段。
- 优先把事务内高频读取的字段全放进一个复合索引：例如事务里总要查
{sku: "A", status: "in_stock"}并投影{available: 1, updatedAt: 1}，那就建db.inventory.createIndex({sku: 1, status: 1, available: 1, updatedAt: 1}) - 避免为每个子操作单独建单字段索引：像
{sku: 1}和{status: 1}并存，事务里find({sku: "A", status: "in_stock"})很可能只用上其中一个，导致keysExamined爆增 - 注意
$in和范围查询（$gt,$lt）在复合索引里的位置：它们必须放在索引末尾，前面字段得是等值匹配，否则覆盖失效。例如find({a: 1, b: {$in: [2,3]}, c: {$gt: 10}})，索引应为{a: 1, b: 1, c: 1}，不能把c放前面
容易被忽略的坑：事务 + 排序 + 分页
事务里做 sort().limit() 是重灾区。即使有索引，如果排序字段不在索引前缀里，就会触发 in-memory sort，而事务不允许使用临时磁盘排序，直接 OOM 或超时。
- 分页查询必须让
sort字段成为索引最左前缀：比如find({userId: "u123"}).sort({createdAt: -1}).limit(10)，索引就得是{userId: 1, createdAt: -1}，不能反过来 - 不要依赖
skip()：事务里skip(1000)仍要扫描前 1000 条，哪怕用了索引。改用游标式分页，把上一页最后的createdAt值带进来：find({userId: "u123", createdAt: {$lt: "2026-04-15T10:00:00Z"}}).sort({createdAt: -1}).limit(10) - 聚合管道在事务中也受同样限制：
$sort阶段若无法利用索引前缀，整个aggregate就会退化为内存计算——而事务默认内存上限仅 100MB
覆盖索引不是加了就万事大吉，它和事务的耦合点在于：事务放大了低效索引的副作用，而覆盖索引是唯一能同时压缩 docsExamined、消除 FETCH、绕过内存排序的手段。实际调优时，永远以事务中最重的那个查询为基准来设计索引，而不是拆成多个轻量查询各自优化。
