理解MongoDB日志中的IXSCAN和COLLSCAN

Question

我试图通过一些Mongo日志实现grep，以找到我需要优化的缓慢操作。默认情况下是慢速查询日志记录，并且日志记录操作超过100 is。

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

考虑到这里的MongoDB文档：

https://docs.mongodb.com/manual/reference/explain-results/#collection-scan-vs-index-use

我的理解是，这是二进制情况，查询要么是COLLSCAN，要么是IXSCAN。因此，如果IXSCAN的grep，我将查看所有非COLLSCANS的慢速查询。这是真的吗？

Answer 1

我试图通过一些Mongo日志实现grep，以找到我需要优化的缓慢操作。默认情况下是慢速查询日志记录，并且日志记录操作超过100 is。

与其浏览MongoDB日志，我强烈建议使用开源mtools项目中的脚本。注:我不是最初的mtools作者，但我是一个贡献者。

mtools是一组Python，它的灵感来自于通过日志的GBs来查找生产MongoDB部署中感兴趣的信息所带来的痛苦。关键脚本是为了适应典型的命令行工作流程，管道输出通过连续过滤器(例如。mlogfilter --scan | mplotqueries)。

例如：

• mloginfo --queries是一个很好的起点:它聚合查询模式，这样您就可以集中精力处理频繁运行并对部署有更全面影响的查询。
• mlogfilter本质上是MongoDB日志的grep :您可以根据名称空间、持续时间、连接、模式和其他条件过滤日志行。--scan选项有助于识别不一定是集合扫描的低效查询。
• mplotqueries是一个可视化日志的工具，它可以非常有助于识别模式和异常值。

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

集合扫描通常是有意义的，但也可能是一次性查询的结果，或者是对一个小集合的预期使用。我将不再关注查询类型，而是检查部署中的慢查询(或一般情况下的慢操作)，以便更好地了解可以改进的内容。使用索引通常是好的，但也有低效的索引用法(例如。内存中的排序( 大小写不敏感正则表达式)是值得寻址的.

我的理解是，这是二进制情况，查询要么是COLLSCAN，要么是IXSCAN。因此，如果IXSCAN的grep，我将查看所有非COLLSCANS的慢速查询。这是真的吗？

如果您在IXSCAN中使用grep，您将发现所有提到IXSCAN的日志行，但是缓慢的查询日志记录结果肯定不是二进制的，并且也会因MongoDB服务器版本而有所不同。虽然高效的索引使用是一个明显的优化，但是有许多内部查询计划阶段可能与理解查询性能相关。

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

值得注意的是，解释查询并不能衡量工作负载的实际性能。在正常操作中，查询计划被缓存，而详细的explain输出则专门重新评估候选索引和查询计划。有关更多信息，请参见查询计划手册中的MongoDB。