MongoDB多条件count查询性能异常排查求助

先从你的执行计划（explain）结果入手分析核心问题：

你的多条件查询最终选择了client.requestInTs_1这个单字段索引，执行流程是先通过索引扫描出2300万条匹配client时间范围的文档条目，再逐个取出完整文档过滤producer的时间条件。这种方式需要大量的磁盘IO读取完整文档，这就是耗时高达100秒的根本原因。虽然你已经创建了(producer.requestInTs, client.requestInTs)的复合索引，但MongoDB 3.4的查询优化器并没有自动选择它——大概率是优化器对双范围查询的成本估算出现了偏差。

下面是针对性的优化步骤，按优先级排序：

1. 强制使用复合索引避免全文档读取 #

既然复合索引包含了两个查询字段，我们可以直接让查询走这个索引，跳过FETCH（读取完整文档）的步骤。在count查询中添加hint()指定复合索引：

db.clean_data.count({
  "producer.requestInTs": {$gte: 0, $lte: 2527594134000},
  "client.requestInTs": {$gte: 0, $lte: 2527594134000}
}).hint("performance")

执行后再用explain()验证：如果计划变成直接扫描复合索引（IXSCAN）后完成统计，不需要FETCH阶段，耗时会大幅降低——因为索引的体积远小于完整文档，扫描速度快很多。

2. 尝试聚合查询替代count #

MongoDB的聚合框架在处理大范围统计时，有时会比原生count更高效，尤其是配合索引使用：

db.clean_data.aggregate([
  {$match: {
    "producer.requestInTs": {$gte: 0, $lte: 2527594134000},
    "client.requestInTs": {$gte: 0, $lte: 2527594134000}
  }},
  {$count: "total_count"}
])

聚合的$match阶段会优先利用索引过滤数据，后续的$count直接基于过滤后的结果统计，避免了count命令可能的额外开销。

3. 检查并整理索引碎片 #

如果索引存在较多碎片，会显著降低扫描速度。你可以先查看索引的碎片情况：

db.clean_data.validate({full: true}).indexDetails["performance"]

如果碎片率较高（比如超过20%），可以在业务低峰期重建索引：

db.clean_data.reIndex("performance")

或者使用compact命令整理集合（注意：compact会锁定集合，需谨慎操作）：

db.runCommand({compact: "clean_data"})

4. 调整WiredTiger缓存配置 #

你的服务器有32GB内存，MongoDB默认的WiredTiger缓存大小是内存的一半（16GB）。如果你的索引和热数据无法完全放入缓存，会导致频繁的磁盘页交换，拖慢查询速度。可以通过修改配置文件或运行时调整缓存大小（比如设置为20GB，留足内存给系统）：

db.adminCommand({setParameter: 1, wiredTigerEngineRuntimeConfig: "cache_size=20G"})

修改后可以通过以下命令监控缓存使用情况，确保没有频繁的页驱逐：

db.serverStatus().wiredTiger.cache

重点关注bytes currently in the cache和pages evicted from cache指标。

5. 考虑升级MongoDB版本 #

你当前使用的是MongoDB 3.4，这个版本已经停止官方支持，后续的3.6+版本对查询优化器做了大量改进：

• 新增了COUNT_SCAN执行阶段，针对count查询可以直接从索引统计，无需遍历所有索引条目
• 优化了双范围查询的索引选择逻辑，更大概率自动选择最优的复合索引
• 对WiredTiger引擎的性能和稳定性也有提升

如果业务允许，升级到较新的稳定版本（比如4.4或5.0）会从根本上改善这类查询的性能。

内容的提问来源于stack exchange，提问作者E. Muuli