如何解决MongoDB事务引起的CPU占用过高问题_定位长耗时操作并添加索引-MongoDB-PHP中文网

先执行db.currentop({"secs_running":{"$gt":5}})筛选运行超5秒的操作，重点关注secs_running、ns和query字段；再启用profiling（setprofilinglevel(1,{slowms:50})），查system.profile中collscan及docsexamined异常高的慢查询，据此优化索引与事务逻辑。

如何解决mongodb事务引起的cpu占用过高问题_定位长耗时操作并添加索引

直接看 `db.currentOp()` 找出卡住的事务

事务本身不直接导致 CPU 高，但未提交、阻塞或长时间运行的事务会拖住锁、堆积查询，间接让 CPU 持续满转。先连上 mongosh，执行 db.currentOp({ "secs_running": { "$gt": 5 } }) —— 这个条件能筛出运行超 5 秒的操作，重点不是“是不是事务”，而是“有没有异常长耗时”。

关注 secs_running 或 microsecs_running 字段值是否远高于业务预期（比如 >30s）
检查 ns（命名空间）和 query，确认是不是你自己的集合和关键查询
若看到 "type": "txn" 且 "active": true，再结合 client 和 secs_running 判断是否来自应用未正确 commit/rollback 的逻辑
别一上来就 kill 所有长事务；先确认客户端是否还在活跃（比如 HTTP 请求已超时但连接没断），否则可能引发二次异常

从 `system.profile` 里抓出真实慢查询

仅靠 db.currentOp() 只能看到“正在跑”的，但很多高 CPU 是由高频慢查询反复触发的。必须开 profiling 看历史：确保 db.setProfilingLevel(1, { slowms: 50 }) 已生效（生产环境推荐 50ms 而非默认 100ms，太松容易漏掉中等压力下的问题）。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

system.profile 中出现 COLLSCAN 就等于没走索引，是 CPU 飙高的头号嫌疑；IXSCAN 但 docsExamined 远大于 keysExamined，说明索引没覆盖查询字段或顺序错
查最近 10 条最耗资源的记录：db.system.profile.find().sort({ "millis": -1 }).limit(10)
注意 millis 是执行时间，nReturned 是返回条数，docsExamined 是扫描条数 —— 后者才是 CPU 开销主因
如果 docsExamined 动辄几万甚至百万，而 nReturned 只有几十，基本可以断定索引缺失或失效

建索引不能只按 `WHERE` 字段硬套

给查询条件字段加索引看似简单，但 MongoDB 的索引生效依赖前缀匹配和排序/分页逻辑。比如查询 { status: "pending", createdAt: { $gt: ISODate(...) } } 并按 createdAt 排序，只建 { status: 1 } 没用。

组合索引顺序必须匹配查询中“等值过滤 → 范围过滤 → 排序字段”结构，例如 { status: 1, createdAt: 1, _id: 1 }
涉及 $in 或多条件 $and 时，避免把高基数字段（如 email）放在索引前面，除非它总是等值匹配
建索引务必加 { background: true } 参数，否则会阻塞写入，尤其在大集合上
建完立刻验证：用 db.collection.explain("executionStats").find(...) 看 executionStages.stage 是否为 IXSCAN，且 docsExamined 接近 nReturned

事务内嵌查询更要警惕索引失效

事务里的查询同样走索引，但有个隐蔽坑：如果事务开启后先写了数据，再读同一集合，MongoDB 可能因快照一致性要求退回到 COLLSCAN —— 尤其当写操作修改了大量文档、触发了索引碎片或版本跳变时。

事务中避免“先 update 大量文档，再 find 同一条件”这类模式；拆成两步，或确保 update 后的 read 查询能命中已有索引
不要在事务里做聚合（$lookup, $group）或跨集合操作，这些天然高 CPU，且无法被单索引优化
如果事务必须含复杂查询，考虑提前在事务外用 db.collection.createIndex() 建好覆盖全部字段的复合索引，而不是依赖事务内自动优化
监控时特别注意 transaction 相关指标：比如 currentTransactions.totalCommitted 和 currentTransactions.totalAborted 比例突增，往往意味着事务设计不合理，而非单纯索引问题