MongoDB查询100万+文档CPU占满100%且响应后仍高负载如何解决？

• 核心原因：name 字段未创建索引，查询触发全表扫描。100万条文档的全表扫描需要逐行比对 name 字段值，直接将CPU占满；即便limit(100)匹配到结果后提前返回响应，MongoDB后台仍可能在处理剩余的扫描收尾、缓存预热相关操作，导致CPU高占用持续10秒左右。你使用的lean()已经优化了Mongoose侧的文档转换开销，查询代码本身没有语法问题。
• 次要诱因1：隐式类型转换导致索引失效。如果Icon Schema中name字段的定义类型和查询传入的字符串类型不匹配（比如字段定义为Number、ObjectId等类型），MongoDB会对每行数据做强制类型转换后再匹配，索引完全失效，等效于全表扫描。
• 次要诱因2：WiredTiger缓存配置不合理。4核8G服务器默认MongoDB会分配50%（4G）内存作为缓存，如果缓存被其他进程挤占，或者手动设置的缓存值过小，查询时会频繁从SSD加载数据到内存，额外拉高CPU占用。

• 1. 为name字段创建单字段索引。在Mongo Shell中执行以下命令：

db.icons.createIndex({name: 1})

如果业务中存在name和其他字段的组合查询场景，可以根据查询模式创建符合最左前缀原则的复合索引，进一步提升查询效率。

• 2. 验证索引生效情况。执行带执行计划分析的查询，确认没有走全表扫描：

db.icons.find({name: 'car'}).limit(100).explain('executionStats')

检查返回结果中executionStats.executionStages.stage字段值，显示IXSCAN即代表索引生效，显示COLSCAN则需要排查索引创建是否正确、是否存在类型不匹配问题。

• 3. 核对字段类型定义。检查Mongoose的Icon Schema中name字段的类型定义，确保和查询传入值的类型完全一致，避免隐式类型转换。
• 4. 优化WiredTiger缓存配置。修改MongoDB配置文件（默认路径/etc/mongod.conf），调整缓存大小为系统内存的50%-60%，8G内存服务器建议设置为3.5G左右：

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 3.5

修改完成后执行systemctl restart mongod重启服务生效。

内容的提问来源于stack exchange，提问作者Hamza Mihfad