mysql - "log_queries_not_using_indexes"中的查询实际上使用了索引

Question

我在 MySQL 中启用了 log_queries_not_using_indexes 选项，尝试消除一些不使用索引的查询，以提高整体性能并减少磁盘上的 I/O。

这是日志文件中的示例:

# User@Host: xxx[xxx] @ localhost []
# Thread_id: 97  Schema: xxx  QC_hit: No
# Query_time: 0.000822  Lock_time: 0.000103  Rows_sent: 0  Rows_examined: 0
SET timestamp=1495617184;
SELECT term_id, meta_key, meta_value
FROM wp_termmeta
WHERE term_id IN (130,202,230,...)
ORDER BY meta_id ASC;

所以我认为它缺少 meta_id 或 term_id 上的索引。

但是两列都有索引，而且表还是空的。

那么为什么这个查询会出现在日志文件中？我实际上可以改进什么？

Answer 1

首先，由于表是空的，现在优化查询的练习可能没有用，当表填充足够多时，执行计划将会改变。

其次，要查看优化器如何选择执行查询，您可以运行

EXPLAIN EXTENDED
SELECT term_id, meta_key, meta_value
FROM wp_termmeta
WHERE term_id IN (130,202,230,...)
ORDER BY meta_id ASC;

或者，如果您运行的是 MariaDB 10.x，请设置 log_slow_verbosity='query_plan,explain'(GLOBAL 或 SESSION 值，具体取决于关于如何执行查询)。

如果您运行解释，您将立即看到该计划。如果您设置了详细程度，则下次当它出现在慢日志中时，您将在慢日志中看到它以及有问题的查询。

该计划很可能会显示 possible_keys 包含 term_id，但 key 实际上是 PRIMARY。如果是这样，则意味着优化器选择不使用 term_id 来查找行(可能是因为没有数据就不值得)，而是使用 PRIMARY 进行排序。由于 log_queries_not_using_indexes 实际上意味着显示不使用索引进行查找的查询，因此它解释了为什么查询最终出现在日志中。

当/如果表中有足够的数据，它很可能会发生变化。反正 table 是空的，这也没什么关系。