先定位慢查询，再分析执行计划并检查索引使用。开启慢查询日志记录耗时SQL，用EXPLAIN分析type、key、rows及Extra信息，确认是否使用索引及是否存在全表扫描。根据查询条件创建复合索引遵循最左前缀原则，避免冗余索引。通过SHOW PROCESSLIST、Performance Schema和OPTIMIZER_TRACE监控运行状态与优化器行为，综合调优高频SQL以预防性能退化。
排查MySQL查询优化问题，关键在于定位慢查询、分析执行计划、检查索引使用情况，并结合系统状态做综合判断。以下是具体步骤和方法。
启用慢查询日志
慢查询日志是发现性能问题的第一步。开启后可以记录执行时间超过指定阈值的SQL语句。
- 在配置文件
my.cnf中添加：
[mysqld] slow_query_log = ON slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = ON
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL log_output = 'FILE';
重启服务或生效后，可通过tail -f /var/log/mysql/slow.log查看慢SQL。
使用EXPLAIN分析执行计划
对可疑SQL使用EXPLAIN或EXPLAIN FORMAT=JSON查看执行路径。
-
type：关注连接类型，从优到劣为
const→eq_ref→ref→range→index→ALL（全表扫描） - key：实际使用的索引，若为NULL需考虑添加索引
- rows：估算扫描行数，越大说明效率越低
-
Extra：出现
Using filesort或Using temporary通常表示需要优化
示例：
EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 'paid';
检查并优化索引
索引设计不合理是常见性能瓶颈。
- 确认查询条件中的字段是否有合适索引，特别是WHERE、JOIN、ORDER BY涉及的列
- 避免过多或重复索引，影响写性能
- 使用复合索引时注意最左前缀原则
- 可借助
SHOW INDEX FROM table_name;查看现有索引 - 考虑使用覆盖索引减少回表次数
例如为上面查询创建复合索引：
CREATE INDEX idx_user_status ON orders(user_id, status);
监控运行状态与资源消耗
通过性能视图了解当前数据库负载。
- 查看正在执行的线程：
SHOW PROCESSLIST;（或SHOW FULL PROCESSLIST;） - 启用Performance Schema获取更详细统计信息
- 查询系统状态变量：
SHOW STATUS LIKE 'Handler%';或SHOW STATUS LIKE 'Key_%'; - 使用
INFORMATION_SCHEMA.OPTIMIZER_TRACE跟踪优化器决策过程（需开启）
开启优化器追踪：
SET optimizer_trace="enabled=on"; SELECT * FROM information_schema.optimizer_trace;
基本上就这些。重点是先抓慢SQL，再用EXPLAIN看执行路径，结合索引和系统状态调优。坚持定期审查高频查询，能有效预防性能退化。
