MySQL性能调优实战：慢查询日志与EXPLAIN执行计划分析

MySQL性能调优第一步不是改配置，是定位慢SQL。线上数据库慢查询日志配合EXPLAIN执行计划，是排查SQL性能问题的标准工具链。本文演示从开启慢查询、抓取耗时语句到分析执行计划、建立索引的完整流程。

开启慢查询日志定位问题SQL

全局打开慢查询日志，设置阈值并确认落盘位置。

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';

# 查看慢查询内容
tail -n 50 /var/lib/mysql/主机名-slow.log
# 汇总分析
mysqldumpslow -s t /var/lib/mysql/主机名-slow.log

生产环境建议阈值设为1秒以内，持续采集一周，按执行时间和频率两个维度排序，优先处理高频慢查询。

EXPLAIN分析执行计划关键列

EXPLAIN SELECT u.name, o.order_no, o.amount
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.status = 1 AND o.create_time > '2026-01-01'
ORDER BY o.create_time DESC
LIMIT 20;

重点看四个字段：type是扫描方式，从好到差依次为system、const、eq_ref、ref、range、index、ALL；key显示实际用到的索引；rows是预估扫描行数；Extra中出现Using filesort、Using temporary说明排序和分组走了临时文件，需要优化。

ALL和index出现在高频SQL上时，基本可以判定索引缺失。

常见索引失效场景与规避

索引列加上函数、隐式类型转换、左模糊、违反最左前缀，都会让索引失效。

-- 失效：索引列被函数包裹
SELECT * FROM orders WHERE DATE(create_time) = '2026-09-09';

-- 生效：改为范围条件
SELECT * FROM orders
WHERE create_time >= '2026-09-09 00:00:00'
  AND create_time < '2026-09-10 00:00:00';

-- 失效：隐式类型转换
WHERE phone = 13800000000;  -- phone列是varchar

-- 生效：字符串形式比较
WHERE phone = '13800000000';

联合索引与覆盖索引优化

高频查询按状态+时间筛选并按时间排序，建立联合索引可同时覆盖筛选与排序。

ALTER TABLE orders ADD INDEX idx_status_create (status, create_time);

SELECT order_no, amount FROM orders
WHERE status = 1
ORDER BY create_time DESC
LIMIT 20;

只查询索引包含的列时，MySQL可以直接从索引返回，不走回表，Extra里出现Using index，属于覆盖索引扫描。

慢查询治理与调优闭环

一条慢SQL的治理路径固定：慢查询日志抓取、EXPLAIN诊断、索引调整、复测、流量观察。重复这个闭环，数据库负载逐步收敛。高并发场景再叠加Redis缓存与读写分离，把热点读从MySQL中拆出去。

调优过程同步做好数据备份恢复演练，任何结构调整都可能引发数据变更，备份是最后一道防线。