了解 MongoDB 日志中的 IXSCAN 和 COLLSCAN

Question

我尝试通过 grep 浏览一些 Mongo 日志，以找到需要优化的慢速操作。慢速查询日志记录是默认设置，记录超过 100 毫秒的操作。

我强烈建议您使用开源脚本，而不是通过 MongoDB 日志进行 grepmtools项目。注意：我不是原作者mtools，但我是一名贡献者。

mtools 是一组 Python 脚本，其灵感来源于在数 GB 的日志中查找所需信息以尝试找到 MongoDB 生产部署所需的信息这一痛苦经历。关键脚本旨在适应通过连续过滤器（例如mlogfilter --scan | mplotqueries）传输输出的典型命令行工作流程。

例如：

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

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

集合扫描通常很有趣，但也可能是一次性查询或对小集合的预期使用的结果。我不会关注查询类型，而是会检查部署中的慢查询（或一般的慢操作），以更好地了解您可以改进的地方。使用索引通常是好的，但存在低效的索引使用（例如内存排序或不区分大小写的正则表达式) 是一个值得解决的问题。

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

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

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

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

Answer 1