sql慢查询排查核心三步：定位慢 SQL、分析执行计划、针对性优化。先通过日志或监控（如mysql slow_query_log、PG log_min_duration_statement）捕获慢 SQL；再用 EXPLai N 查看 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 输出一行行读明白。
