理解MongoDB日志中的IXSCAN和COLLSCAN

我试图通过一些Mongo日志grep试图find我需要优化的慢操作。 查询日志logging缓慢，默认情况下，logging操作超过100毫秒。

我会强烈推荐使用开源mtools项目中的脚本，而不是通过MongoDB日志进行查询。 注意：我不是原始的mtools作者，但我是贡献者。

mtools是Python脚本的一个集合，它受到了通过GB日志logging的痛苦，试图find生产MongoDB部署感兴趣的信息。 关键脚本旨在通过连续的filter（例如， mlogfilter --scan | mplotqueries ）与pipe道输出的典型命令行工作stream相mlogfilter --scan | mplotqueries 。

例如：

• mloginfo --queries是一个很好的起点：它聚合了查询模式，因此您可以专注于频繁运行的查询，并对部署有更大的整体影响。
• mlogfilter本质上是MongoDB日志的一个grep：你可以按命名空间，持续时间，连接，模式和其他标准过滤日志行。 --scan选项有助于识别不一定是集合扫描的低效查询。
• mplotqueries是一个可视化日志的工具，可以帮助识别模式和exception值。

我认为可以肯定地说，一般来说，searchCOLLSCANS将显示需要注意的查询。 不太清楚的是，如果IXSCANS是一个细节，我应该search。

收集扫描通常是有意义的，但也可能是一次性查询或预期在小集合上使用的结果。 我不会关注查询types，而是会为您的部署查看缓慢的查询（或通常较慢的操作），以更好地了解您可能能够改进的内容。 使用索引通常是很好的，但是存在效率不高的索引用法（例如，内存中的sorting或不区分大小写的正则expression式 ）可能值得处理。

我的理解是，这是一个二进制情况，查询是COLLSCAN或IXSCAN。 所以，如果我grep IXSCAN，我会看所有不是COLLSCANS慢查询。 这是真的？

如果你grep的IXSCAN你会发现所有日志行提到IXSCAN ，但慢速查询日志logging的结​​果是绝对不是二进制的，也会因MongoDB服务器版本而有所不同。 虽然有效的索引使用是一个明显的优化，但是有一些内部查询计划阶段可能与理解查询性能有关。

当您在日志中发现有趣的慢查询时，下一步通常是查看更详细的explain output 。 我使用explain(true) （又名allPlansExecution模式），因为这显示了查询计划的细节以及获胜计划。 如果您不确定如何解释缓慢查询的解释输出，我build议在DBA StackExchange上发布。

值得注意的是，解释一个查询并不是衡量一个工作量的实际performance。 在正常操作中查询计划被caching，而详细的explain输出特别重新评估候选索引和查询计划。 有关更多信息，请参阅MongoDB手册中的查询计划 。