SQL慢查询排查核心三步：定位慢SQL、分析执行计划、针对性优化。先通过日志或监控（如MySQL slow_query_log、PG log_min_duration_statement）捕获慢SQL；再用EXPLAIN查看type、rows、Extra、Index Key Usage等关键指标；最后按没走索引、索引失效、数据量大、统计信息过期四类精准优化，并验证固化。
SQL慢查询排查核心就三步：定位慢SQL、分析执行计划、针对性优化。不靠猜，不靠经验堆砌，而是用数据库自带工具+逻辑推演，快速锁定瓶颈点。下面按真实排查流程拆解，每一步都带操作命令和判断依据。
第一步：从日志或监控里揪出慢SQL
慢SQL得先看见，才能处理。不同数据库入口不同：
- MySQL：打开slow_query_log，设置long_query_time=1（单位秒），日志默认存/var/lib/mysql/slow.log；也可用SHOW PROCESSLIST实时看正在跑的长事务
- PostgreSQL：配置log_min_duration_statement = 1000（毫秒），日志路径看log_directory和log_filename
- 生产环境建议接Prometheus+Grafana，用pg_stat_statements（PG）或performance_schema.events_statements_summary_by_digest（MySQL）聚合统计TOP耗时SQL
第二步：用EXPLAIN看执行计划，盯死这4个关键指标
拿到慢SQL后，别急着改，先加EXPLAIN FORMAT=TREE（MySQL 8.0+）或EXPLAIN (ANALYZE, BUFFERS)（PG），重点看：
- type / Join Type：出现ALL（全表扫描）或index（全索引扫描）基本就是没走对索引
- rows / Rows Removed by Filter：预估扫描行数远大于实际返回行数，说明过滤条件没生效或索引覆盖不全
- Extra：看到Using filesort、Using temporary大概率要优化排序或分组逻辑
- Index Key Usage：确认key字段是否命中预期索引，key_len是否合理（比如varchar(255)只用了前10个字节，可能前缀索引太短）
第三步：按常见瓶颈类型精准优化
不是所有慢都靠加索引解决，得分类施策：
- 没走索引：检查WHERE字段是否有函数操作（如WHERE YEAR(create_time) = 2024）、隐式类型转换（字符串ID用数字查）、OR条件未统一索引路径
- 索引失效：联合索引最左匹配被破坏（INDEX(a,b,c)，但查询只用了b = ?）、范围查询后列无法走索引（a = ? AND b > ? AND c = ?中c不生效）
- 数据量大但必须查：考虑分页优化（用WHERE id > last_id LIMIT 20替代OFFSET）、冷热分离（把历史归档表单独拆出）、读写分离分摊压力
- 统计信息过期：执行ANALYZE TABLE xxx（MySQL）或ANALYZE xxx（PG），让优化器重算成本模型
第四步：验证+固化，避免反复踩坑
改完不是结束，得闭环验证：
- 在测试库用EXPLAIN ANALYZE对比前后执行计划和实际耗时
- 上线前做压测，观察QPS、连接数、CPU是否突增（有时优化了单条，却引发锁竞争）
- 把修复后的SQL和对应索引语句记入团队Wiki，标注适用场景（比如“该索引仅适用于status IN (1,2)且create_time倒序分页”）
- 在CI流程中加入SQL审核（用soar或archer），自动拦截全表扫描、缺失WHERE、ORDER BY无索引等高危写法
基本上就这些。慢查询不是玄学，是可测量、可追踪、可复现的问题。工具摆在那里，逻辑链路也清晰，卡住的往往不是技术，而是有没有耐心把EXPLAIN输出一行行读明白。
