MySQL慢查询优化核心是“先定位、再分析、后改进”，需正确配置慢查询日志（slow_query_log=ON、long_query_time=1.0、log_queries_not_using_indexes=ON），用pt-query-digest分析瓶颈，针对性优化无索引查询、ORDER BY、分页及隐式转换问题，并通过EXPLAIN和监控闭环验证。
MySQL 慢查询优化的核心是“先定位、再分析、后改进”，关键不在于盲目调参，而在于读懂慢查询日志传递的真实信号。
开启并正确配置慢查询日志
慢查询日志是优化的起点，但默认关闭且参数易设错。需确保以下三点生效：
- log_slow_queries 已弃用，应使用 slow_query_log = ON
- long_query_time 建议设为 1.0（秒），高并发场景可临时调至 0.5，避免漏掉有隐患的“亚秒级”高频慢查
- 务必启用 log_queries_not_using_indexes = ON，它能暴露缺少索引的隐性低效查询，即使执行时间未超阈值
- 日志建议输出到文件（slow_query_log_file = /var/lib/mysql/slow.log），而非表，避免影响性能和权限问题
用 pt-query-digest 快速识别瓶颈SQL
人工翻日志效率极低。Percona Toolkit 的 pt-query-digest 是事实标准工具，一条命令即可提炼关键信息：
- pt-query-digest /var/lib/mysql/slow.log --limit 10：列出耗时/次数/锁等待最严重的前10类查询
- 重点关注 Query_time avg 和 Rows_examined avg 的比值——若扫描行数远大于返回行数（如 10000:1），大概率存在索引缺失或索引失效
- 注意 EXPLAIN 输出中出现 Using filesort 或 Using temporary 的语句，这类操作极易成为性能拐点
针对性优化常见慢查模式
多数慢查集中在几类典型场景，按优先级逐个击破：
- 无索引 WHERE 条件：对 WHERE a=1 AND b=2 这类多条件查询，建联合索引要遵循 等值字段在前、范围字段在后（如 INDEX(a,b)），而非 (b,a)
- ORDER BY 无法走索引：当 ORDER BY create_time DESC LIMIT 20 出现在大表上，且 create_time 无索引或索引选择性差，应补索引；若涉及多字段排序（如 ORDER BY status, create_time），需创建对应联合索引
- SELECT * 在分页场景下危害极大：用 LIMIT 100000,20 时，MySQL 仍要扫描前100020行。改用基于游标的分页（如 WHERE id > 123456 ORDER BY id LIMIT 20）可彻底规避
- 隐式类型转换：如字段是 VARCHAR(20)，但查询写成 WHERE mobile = 13800138000（数字），会导致索引失效。统一用字符串引号包裹值
验证与持续监控不可少
优化不是一次性的动作，必须闭环验证：
- 每改一个 SQL 或索引，用 EXPLAIN FORMAT=JSON 对比前后执行计划，确认 rows_examined 显著下降、key 字段命中预期索引
- 上线后观察慢查日志增长速率，可用脚本每日统计 grep "Query_time" slow.log | wc -l 并对比基线
- 将 slow_query_log = ON 作为生产库标配，配合监控告警（如 Prometheus + mysqld_exporter），当慢查数量突增 300% 自动通知
