我在 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
上的索引。
但是两列都有索引,而且表还是空的。
那么为什么这个查询会出现在日志文件中?我实际上可以改进什么?
最佳答案
首先,由于表是空的,现在优化查询的练习可能没有用,当表填充足够多时,执行计划将会改变。
其次,要查看优化器如何选择执行查询,您可以运行
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 是空的,这也没什么关系。
关于mysql - "log_queries_not_using_indexes"中的查询实际上使用了索引,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44153741/