首先开启慢查询日志并配置long_query_time等参数，然后使用mysqldumpslow或pt-query-digest分析日志定位高频或耗时SQL，接着通过EXPLAIN检查执行计划发现全表扫描或索引失效问题，最后采取创建索引、优化SQL语句等措施进行调优，并持续验证效果形成闭环。
当MySQL出现性能问题时，慢查询往往是主要原因之一。通过分析和优化这些执行效率低下的SQL语句，可以显著提升数据库响应速度。关键在于定位哪些SQL执行时间过长，并针对性地进行调优。
开启慢查询日志
要分析慢查询，第一步是确保慢查询日志已启用。只有记录了慢SQL，才能进一步分析。
在MySQL配置文件（如my.cnf或my.ini）中添加以下配置：
- slow_query_log = ON：开启慢查询日志功能
- slow_query_log_file = /var/log/mysql/slow.log：指定日志存储路径
- long_query_time = 1：设置超过1秒的查询被记录（可根据需要调整）
- log_queries_not_using_indexes = ON：记录未使用索引的查询，便于发现潜在问题
修改后重启MySQL服务，或在运行时动态设置（部分参数支持SET GLOBAL）。
使用mysqldumpslow或pt-query-digest分析日志
慢查询日志生成后，直接查看文本效率低下。推荐使用工具提取高频、耗时长的SQL。
- mysqldumpslow -s c -t 10 slow.log：按出现次数排序，显示前10条最频繁的慢SQL
- mysqldumpslow -s t -t 10 slow.log：按总执行时间排序，找出最耗资源的SQL
- pt-query-digest（Percona Toolkit提供）功能更强，可生成详细报告，包括执行计划、等待事件等
这些工具能帮助你快速锁定需要优化的重点SQL语句。
利用EXPLAIN分析执行计划
对定位到的慢SQL，使用EXPLAIN命令查看其执行计划，判断是否存在全表扫描、索引失效等问题。
- EXPLAIN SELECT * FROM users WHERE name = 'john';：查看该查询的执行方式
- 重点关注type字段：ALL表示全表扫描，应尽量避免；index或range更理想
- key字段显示实际使用的索引，若为NULL说明未走索引
- Extra字段出现Using filesort或Using temporary时，通常意味着排序或临时表开销大，需优化
结合执行计划结果，判断是否需要添加索引、重写SQL或调整表结构。
常见优化策略
根据分析结果，采取具体措施提升SQL性能。
- 为WHERE、ORDER BY、GROUP BY涉及的列创建合适索引，但避免过度索引影响写入性能
- 避免SELECT *，只查询必要字段，减少数据传输量
- 拆分复杂查询，用多个简单查询替代JOIN过多的大SQL
- 使用LIMIT限制返回行数，尤其是在分页场景中
- 定期分析表（ANALYZE TABLE）更新统计信息，让优化器选择更优执行路径
优化后再次观察慢查询日志，确认效果。
基本上就这些。关键是形成“记录→分析→优化→验证”的闭环。只要坚持监控慢查询，多数性能问题都能提前发现并解决。
