sql慢查询排查核心是定位瓶颈、分析执行计划、针对性优化。重点不在盲目加索引，而在理解数据访问路径和资源消耗点。
开启并收集慢查询日志
确保mysql已启用慢查询日志功能，并合理设置阈值（如 long_query_time = 1），避免日志过大影响性能。推荐同时开启 log_queries_not_using_indexes，辅助发现隐式全表扫描。
- 检查是否启用：red”>SHOW varIABLES LIKE ‘slow_query_log’;
- 确认日志路径：SHOW VARIABLES LIKE ‘slow_query_log_file’;
- 临时启用（不重启）：SET GLOBAL slow_query_log = ON;
- 建议将日志输出到专用文件，并配合 logrotate 定期归档
快速定位问题SQL（使用mysqldumpslow或pt-query-digest）
原始慢日志可读性差，需借助工具聚合分析。优先关注出现频率高、平均耗时长、锁等待久的SQL。
- mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log：按总耗时排序取前10条
- pt-query-digest /var/lib/mysql/slow.log –limit 10：更详细统计（需安装Percona Toolkit）
- 重点关注Rows_examined远大于Rows_sent的语句——说明扫描多、过滤差
分析执行计划（EXPLAIN + format=jsON）
对可疑SQL执行EXPLAIN FORMAT=json，比传统EXPLAIN更直观展现访问类型、是否用索引、是否临时表/文件排序等关键信息。
- 看type字段：ALL/INDEX表示全表或全索引扫描，需优化；range/ref/eq_ref较健康
- 看key和possible_keys：是否命中预期索引？有无索引失效（如对索引列做函数、隐式类型转换）
- 看Extra字段：出现Using filesort、Using temporary、Using join buffer说明存在排序/临时表开销
- 注意filtered值过低（如
常见优化方向与验证方式
优化不是“加索引就完事”，要结合业务逻辑和数据分布判断。改完必须复测，对比Rows_examined、执行时间、QPS变化。
- 补索引：覆盖查询所需字段（避免回表），注意最左匹配原则，区分等值与范围条件位置
- 改写SQL：拆分复杂JOIN、避免SELECT *、用EXISTS替代IN（尤其子查询结果大时）
- 调整参数：适当增大sort_buffer_size（单次排序）、join_buffer_size（关联内存），但需评估内存压力
- 分区或归档：对历史数据量大的表，按时间分区或冷热分离，减少单次扫描范围
- 验证效果：在测试环境用EXPLAIN ANALYZE（MySQL 8.0.18+）看真实执行流程与耗时分布