MongoDB 系统IOPS 告警系统处于崩溃，优化语句从1秒优化到1毫秒解决问题

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2340人左右 1 + 2 + 3 + 4 +5 + 6 + 7）(1 2 3 4 5 群均已爆满，请不要在问有没有位置谢谢)

（文章最后有MongoDB 8.0 新功能发布会的时间和宣传页，可在线观看）

MongoDB 运行中在没有任何变动业务和访问量的情况下，系统突发的故障如IOPS升高的情况，在我们系统运行的过程中发生了这样的问题，这里就记录一下故障的发生和解决故障的整体的情况。

故障的版本是MongoDB 4.2.13,其中有一个collection，37G大小，说大不大，说小不小，其中这个表中有聚合的查询，我们在使用中已经进行了优化先对可以过滤掉的数据进行match后，在进行聚合，虽然速度不快，但也可以接受基本在500ms之内。

但此次导致IOPS 升高的语句并不是这个，而是一个普通的查询语句

{"op":"query","ns":"wuce.P_IN","command":{"find":"P_IN","filter":{"mc":312168,"isdo":0,"invosta":0,"inve":{"$gte":{"$date":"2024-07-10T00:00:00.000+0800"}}},"$db":"ice","$clusterTime":{"clusterTime":{"$timestamp":{"t":1722304726,"i":5}},"signature":{"hash":{"$binary":"4pflEud2+pykfWQq206k6iEF++w=","$type":"00"},"keyId":{"$numberLong":"7338309997287178243"}}},"lsid":{"id":{"$binary":"e0+tCitWT+GndKXFGzpz9A==","$type":"04"}},"$readPreference":{"mode":"primaryPreferred"}},"cursorid":{"$numberLong":"7403234999028736853"},"keysExamined":3484,"keysExaminedBySizeInBytes":87100,"docsExamined":3484,"docsExaminedBySizeInBytes":3894571,"numYield":36,"nreturned":101,"queryHash":"1BAEAE7B","planCacheKey":"67ED178C","locks":{"ReplicationStateTransition":{"ant":{"w":{"$numberLong":"38"}}},"Global":{"acquit":{"r":{"$numberLong":"38"}}},"Database":{"nt":{"r":{"$numberLong":"37"}}},"Collection":{"acquireCount":{"r":{"$numberLong":"37"}}},"Mutex":{"acquireCount":{"r":{"$numberLong":"1"}}}},"flowControl":{},"storage":{"data":{"bytesRead":{"$numberLong":"81574572"},"timeReadingMicros":{"$numberLong":"968849"}}},"responseLength":114228,"protocol":"op_msg","millis":999,"planSummary":"IXSCAN { mcid: 1, invte: 1, bupe: 1, iswn: 1 }","replRole":{"stateStr":"PRIMARY","_id":0}}

{"op":"query","ns":"wuce.P_IN","command":{"find":"P_IN","filter":{"mc":312168,"isdo":0,"invosta":0,"inve":{"$gte":{"$date":"2024-07-10T00:00:00.000+0800"}}},"$db":"ice","$clusterTime":{"clusterTime":{"$timestamp":{"t":1722304726,"i":5}},"signature":{"hash":{"$binary":"4pflEud2+pykfWQq206k6iEF++w=","$type":"00"},"keyId":{"$numberLong":"7338309997287178243"}}},"lsid":{"id":{"$binary":"e0+tCitWT+GndKXFGzpz9A==","$type":"04"}},"$readPreference":{"mode":"primaryPreferred"}},"cursorid":{"$numberLong":"7403234999028736853"},"keysExamined":3484,"keysExaminedBySizeInBytes":87100,"docsExamined":3484,"docsExaminedBySizeInBytes":3894571,"numYield":36,"nreturned":101,"queryHash":"1BAEAE7B","planCacheKey":"67ED178C","locks":{"ReplicationStateTransition":{"ant":{"w":{"$numberLong":"38"}}},"Global":{"acquit":{"r":{"$numberLong":"38"}}},"Database":{"nt":{"r":{"$numberLong":"37"}}},"Collection":{"acquireCount":{"r":{"$numberLong":"37"}}},"Mutex":{"acquireCount":{"r":{"$numberLong":"1"}}}},"flowControl":{},"storage":{"data":{"bytesRead":{"$numberLong":"81574572"},"timeReadingMicros":{"$numberLong":"968849"}}},"responseLength":114228,"protocol":"op_msg","millis":999,"planSummary":"IXSCAN { mcid: 1, invte: 1, bupe: 1, iswn: 1 }","replRole":{"stateStr":"PRIMARY","_id":0}}

这里将关键的信息都修改了，信息仅作为展示使用，可以从语句分析的信息中看到运行的时间已经到达了 999 毫秒，这已经属于MongoDB的慢查询了，从语句中分析语句中已经走了索引。但是MongoDB 给我们更多的信息，这相比传统数据库要好的多，我们看一下下面的分析

keysExamined: 3484：这个字段表示查询过程中 MongoDB 检查了 3484 个索引键。

keysExaminedBySizeInBytes: 87100：这个字段表示 MongoDB 在检查索引键时处理的总字节数为 87100 字节。

docsExamined: 3484：这个字段表示 MongoDB 在查询过程中检查了 3484 个文档。通常，keysExamined 和 docsExamined 数值相同，表示 MongoDB 需要对每个索引键对应的文档进行检查。

docsExaminedBySizeInBytes: 3894571：这个字段表示 MongoDB 在检查文档时处理的总字节数为 3894571 字节。

numYield: 36：这个字段表示查询过程中，MongoDB 让出（yield）了 36 次 CPU 控制权，以便处理其他操作。让出 CPU 控制权通常是在长时间运行的查询中为了避免锁定数据库而执行的操作。

nreturned: 101：这个字段表示查询返回了 101 个结果文档。

这里我们分析一下上述的信息，查询返回了101个结果，numYield 36次，并且和上面相比如果高频的每次都要在非常少的数据量查找要用到 3.7MB的数据中查找几个KB的数据，那么的确这个查询要不从逻辑上，要不从查询上要进行优化了。

但架构和开发反馈，之前一直没有对这个部分动过什么，突发性的就慢了。后面我们经过分析，发现其中有一个时间字段在索引里面并不存在但是现在查询在索引里面没有这个字段。

经过了解，之前加字段的时候，也尝试过但发现添加时间字段到索引后，查询的速度并没有特别大的变化，可能是当时的数据量小，但现在表大了，并且数据量堆积的厉害，这边我们就建议添加索引加上这个时间的字段，来看是否解决当前的问题。

在添加了的索引后，再次运行语句，我们从其中摘取执行的时间，1毫秒，优化完毕，参见下面的图中最后截取的执行语句的时间信息。

结论：在MongoDB运行中，随着时间的推移和数据量的加大，有些以前可以完美运行的索引可能在数据量达到一定情况下，失去索引应有的作用。