MongoDB 3.4聚合查询异常咨询：高CPU、全表扫描及游标弃用问题

1. 108ms的查询耗时是否正常？ #

从你提供的执行计划来看：

planSummary: COLLSCAN keysExamined:0 docsExamined:2263 hasSortStage:1 numYields:19 nreturned:0 reslen:50

这个108ms的耗时表面数值不算极端，但结合CPU直接拉满到99%的情况，本质是不正常的——它背后是MongoDB在全表扫描+内存紧张的双重压力下，被迫频繁让出锁（numYields:19）、CPU满负荷处理扫描和排序操作导致的。正常情况下，2000多条文档的查询应该远低于这个耗时，且绝不会触发CPU过载。

2. 弃用警告与cursor选项能否解决CPU过高问题？ #

关于弃用警告 #

MongoDB 3.4里，不带cursor选项的aggregate命令确实会触发弃用警告，因为默认的一次性返回结果（inline模式）在结果集较大时会占用大量内存，官方推荐用游标分批获取结果。虽然当前查询还能跑，但建议尽快改成带cursor的写法，比如：

db.collection.aggregate([/* 你的聚合管道逻辑 */], { cursor: {} })

cursor能否解决CPU过高？ #

答案是不能直接解决。CPU飙升的核心根源是这几个问题：

• 全表扫描（COLLSCAN）：完全没用到索引，MongoDB需要遍历所有2263条文档，CPU消耗巨大；
• 内存排序（hasSortStage:1）：排序操作没利用索引，得在内存里完成排序，而你的MongoDB仅分配1GB内存，内存紧张会触发频繁的内存交换，进一步把CPU拉满；
• 内存不足：1GB内存对于MongoDB来说过于局促，WiredTiger引擎的缓存空间不够，会频繁从磁盘读数据，CPU还要额外处理IO和内存管理的开销。

cursor选项的作用是分批返回结果，减少单次内存占用，但它没法改变全表扫描和内存排序的本质，所以不能直接降低CPU负载。不过启用cursor符合官方最佳实践，能避免后续结果集变大时的内存过载问题，也能消除弃用警告，建议开启。

3. 解决CPU过载的核心方案 #

• 添加针对性索引：针对聚合管道里的过滤条件和排序字段创建复合索引，把COLLSCAN改成IXSCAN——这是降低CPU最有效的手段，既能避免全表扫描，还能让排序直接利用索引完成（消除hasSortStage:1）；
• 升级内存配置：AWS上1GB内存不足以支撑MongoDB的正常缓存需求，建议升级到至少2GB以上的实例，或者调整WiredTiger的cacheSizeGB参数（默认是系统内存的50%，1GB实例下就是512MB，可根据实际情况微调）；
• 优化查询逻辑：你的查询返回结果为0（nreturned:0），可以检查过滤条件是否过于严格或存在逻辑问题，提前过滤掉不需要的文档，减少扫描的文档数量；
• 启用cursor选项：虽然不能直接解决CPU问题，但符合官方规范，能避免弃用警告，同时降低内存压力。

内容的提问来源于stack exchange，提问作者Curious Developer