EXPLAIN输出字段全解析：读懂MySQL的执行意图

MySQL的EXPLAIN是SQL调优的起点，但很多人的解读停留在type列是否出现ALL。实际上，EXPLAIN的12个输出字段每个都携带关键信息，遗漏任何一个都可能导致调优方向错误。下面逐字段拆解重点：

id列：标识SELECT的序号。子查询和UNION会产生多个id，id越大越先执行。一个常见误区是认为id相同的行按从上到下顺序执行——实际上id相同的行是并列关系，执行顺序由优化器决定，需要结合rows估算综合判断。

type列：访问类型，从最优到最差的排序：system > const > eq_ref > ref > range > index > ALL。生产环境中，核心查询的type至少要达到ref级别。index类型虽然看起来不错，但它本质上是全索引扫描，如果索引不能覆盖查询列，还需要回表，性能可能比ALL还差。

key列与key_len列：key显示实际使用的索引，key_len显示使用的索引长度。key_len是判断复合索引使用情况的关键指标。一个VARCHAR(50)的列在utf8mb4编码下，单列索引的key_len是50×4+2=202字节（2字节是长度前缀）。如果复合索引是(col_a, col_b)，key_len=4说明只用了col_a（INT类型4字节），key_len=206说明col_a和col_b都用上了（4+202=206）。

-- 查看完整执行计划（包含分区和额外信息）
EXPLAIN FORMAT=JSON
SELECT o.order_id, o.amount, u.user_name
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.create_time BETWEEN '2026-07-01' AND '2026-07-31'
  AND o.status = 'PAID'
ORDER BY o.amount DESC
LIMIT 20;

FORMAT=JSON输出比表格输出多了三个关键信息：used_key_parts（实际使用了索引的哪些列）、attached_condition（哪些条件是索引过滤后的二次过滤）、cost_info（优化器的成本估算）。这三个信息在判断索引是否有效利用时至关重要。

慢SQL诊断实战：从slow log到优化方案

慢SQL治理的第一步是建立可靠的采集机制。MySQL的slow_query_log配置需要注意几个细节：

# my.cnf 慢日志配置
slow_query_log = 1
slow_query_log_file = /data/mysql/slow.log
long_query_time = 0.5
log_queries_not_using_indexes = 1
min_examined_row_limit = 100

# 动态修改（无需重启）
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 0.5;

long_query_time设置为0.5秒而非常见的2秒或1秒，是因为在OLTP场景下，500ms已经是用户可感知的延迟阈值。记录更细的粒度才能捕获到所有需要关注的SQL。

慢日志分析工具的选择：pt-query-digest是标准工具，输出最完整的分析报告：

# 分析最近24小时的慢查询
pt-query-digest /data/mysql/slow.log   --since '24h ago'   --limit 20   --order-by Query_time:sum

# 输出关键指标解读：
# 1. Query_time:sum - 总耗时排序，找到累计消耗最大的SQL
# 2. Rows_examined - 扫描行数，与Rows_sent的比值越大说明效率越低
# 3. Lock_time - 锁等待时间，高Lock_time说明有锁竞争

一个典型的慢SQL优化案例：

-- 原始SQL（执行时间3.2秒）
SELECT * FROM orders
WHERE user_id = 10086
  AND status IN ('PAID', 'SHIPPED')
  AND create_time > '2026-06-01'
ORDER BY update_time DESC
LIMIT 50;

-- EXPLAIN分析
-- type: ref, key: idx_user_id, rows: 128000
-- Extra: Using where; Using filesort
-- 问题：idx_user_id只覆盖了user_id，status和create_time是回表后过滤
-- filesort说明排序没走索引

-- 创建优化索引
ALTER TABLE orders
ADD INDEX idx_user_status_time (
  user_id, status, create_time, update_time
);

-- 优化后执行计划
-- type: ref, key: idx_user_status_time, rows: 2300
-- Extra: Using index condition; Backward index scan
-- 执行时间：18ms（提升177倍）
--
-- 解读：
-- 1. user_id, status走索引等值匹配，快速定位
-- 2. create_time走索引范围扫描
-- 3. update_time用于排序，避免filesort
-- 4. Backward index scan: 利用索引的降序扫描避免额外排序

索引设计陷阱：覆盖索引与回表的取舍

覆盖索引是避免回表的最有效手段，但过度使用会导致索引膨胀和写入性能下降。一个实用的判断标准：如果查询返回的列数超过5个，覆盖索引的收益通常不值得索引膨胀的代价。合理的做法是：高频查询做覆盖索引，低频查询容忍回表。

另一个常见陷阱是多范围查询无法走索引。当一个SQL中同时有两个范围条件时，MySQL只能用索引的第一个范围列，后面的范围列需要回表过滤：

-- 问题SQL：两个范围条件
SELECT * FROM products
WHERE category_id = 5
  AND price BETWEEN 100 AND 500
  AND stock > 0
ORDER BY sales DESC
LIMIT 20;

-- 索引 idx_category_price_stock(category_id, price, stock)
-- 实际执行：category_id走索引，price走索引范围
-- 但stock > 0无法继续走索引，需要回表检查
-- 因为price是范围条件，后续的stock列在B+Tree上不再有序

-- 解决方案1：修改业务逻辑，将stock > 0改为冗余字段is_in_stock
-- 索引：idx_category_price(category_id, is_in_stock, price)
-- 这样三个条件都能走索引

-- 解决方案2：对核心查询做反范式化，预计算热门分类的在售商品
-- 用物化视图或定时任务维护

MySQL 8.0的索引优化还有一个容易被忽视的特性：索引跳扫描（Index Skip Scan）。当一个复合索引的前导列区分度很低时，MySQL 8.0可以跳过前导列，对后续列做索引扫描。但这个特性有严格的前提：前导列的不同值数量很少（通常少于几十个），且查询条件不包含前导列。在实际项目中不要过度依赖这个特性，显式创建合适的索引才是可靠方案。

MySQL 8.0性能监控仪表盘核心指标

数据库运维的可观测性建设需要关注以下performance_schema指标：

-- 1. 当前活跃连接与连接历史
SELECT * FROM performance_schema.threads
WHERE PROCESSLIST_STATE IS NOT NULL;

-- 2. 等待事件Top 10（找出最耗时的操作）
SELECT EVENT_NAME, COUNT_READ, SUM_TIMER_READ/1000000000 AS read_sec
FROM performance_schema.file_summary_by_instance
ORDER BY SUM_TIMER_READ DESC LIMIT 10;

-- 3. 索引使用统计（找出未使用的索引）
SELECT object_schema, object_name, index_name
FROM performance_schema.table_io_waits_summary_by_index_usage
WHERE count_star = 0 AND index_name IS NOT NULL
  AND object_schema NOT IN ('mysql', 'performance_schema');

定期清理未使用索引是数据库运维的基本功。每个多余的索引都在消耗写入性能和磁盘空间，通过performance_schema的数据驱动决策，比主观判断更可靠。SQL调优没有万能公式，但EXPLAIN读懂、慢日志用好、索引设计合理这三个基本功扎实了，80%的性能问题都能快速定位和解决。