MYSQL 8.0.34版，启用了以下变量：
log_queries_not_using_indexes = ON
slow_query_log = ON表格示例：
CREATE TABLE `countries` (
`id` tinyint UNSIGNED NOT NULL,
`country` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
ALTER TABLE `countries`
ADD PRIMARY KEY (`id`);
ALTER TABLE `countries`
MODIFY `id` tinyint UNSIGNED NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=69;
COMMIT;数据类型：
id | country
1 | Afghanistan
2 | Albania
3 | Algeria
4 | Andorra
5 | Angola查询方式：
SELECT id, country AS country_name FROM countries解释输出EXPLAIN SELECT id, country FROM countries：
id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra
1 | SIMPLE | countries | NULL | ALL | NULL | NULL | NULL | NULL | 63 | 100.00 | NULL记录的查询：
# Time: 2023-10-10T14:57:36.980019Z
# User@Host: db_user[db_user] @ localhost [127.0.0.1] Id: 2710
# Query_time: 0.000140 Lock_time: 0.000003 Rows_sent: 63 Rows_examined: 63
use db_name;
SET timestamp=1696863456;
select id, country AS country_name from `countries`;id是主要的，自动递增，所以这很奇怪。
我应该忽略这样的查询日志，还是结构或查询有问题？
1条答案
按热度按时间w8f9ii691#
您显示的EXPLAIN报告包括列
type: ALL，这表明它正在使用表扫描阅读查询。它不使用索引。该查询没有筛选条件或排序子句，因此没有必要使用索引。在任何应用程序中，都可能有许多这样的查询自然不使用索引，但这是设计好的。
这意味着
log_queries_not_using_indexes选项的实用性非常有限。它可能会导致大量查询被记录，而不会给您提供可操作的信息。它还可能记录需要注意优化的查询，但它们往往会在日志中丢失在不需要注意的查询的许多条目中。我通常不启用
log_queries_not_using_indexes，除非是在尝试诊断特定问题查询时临时启用。