慢SQL急诊室·贴上EXPLAIN就开方

先看清你要解决的问题

一条接口从 200ms 变成 3s，SHOW PROCESSLIST 里那条 SQL 的 Time 越爬越高，slow_query_log 刷到几十 MB。翻 EXPLAIN，可能只看到 type: ALL 和一串 NULL，rows 是 800 万，Extra 里挂着 Using filesort 和 Using temporary。

慢查询真正让人头疼的地方不在"慢"，而在原因分散在三层：执行计划里的扫描方式、索引设计与 SQL 写法之间的错配、以及锁等待和长事务引发的偶发抖动。排查时容易只改一处：看到 filesort 就加索引，结果写放大没算清；看到 OR 就拆查询，结果还是全表扫描。

它怎么工作

这个技能按"先诊断、再开方"的方式组织，输出固定分四个章节：

• 病灶定位：逐列解读 type、key、rows、Extra，直接引用 EXPLAIN 原文指出哪一步最贵。常见异常如全表扫描、临时表落盘、rows 估计爆炸、filesort 触发，会按"预期收益 × 实施成本"排序。
• 处方：每条方案都带可直接执行的语句。索引用 idx_表名_列名 规范命名，同时说明命中哪个查询条件、是否覆盖索引、对写入的影响；改写后的 SQL 覆盖 SELECT *、隐式类型转换、函数包列、深分页（改游标或延迟关联）和大 IN（改临时表或分批）。
• 预期收益与代价：给出改造后执行计划应有的特征，并指导你写对比验证 SQL，拿前后 rows 和实际耗时说话，不拍脑袋保证提速倍数。
• 上线风险清单：每条方案附回滚语句、在线加索引方式（如 ALGORITHM=INPLACE、gh-ost、pt-osc）与验证 SQL。

锁与事务相关的问题也被覆盖：从"偶发变慢"中识别锁等待、长事务、间隙锁场景，给出定位命令和对应的解法。你也可以直接贴一段慢日志，技能会按"出现频次 × 单次耗时"排出需要优先救治的 Top 5。

适用边界与注意点

• 支持 MySQL、PostgreSQL、SQL Server 等关系型数据库，但版本差异显著时（例如 MySQL 5.7 与 8.0）会先确认版本再开方。
• 只做诊断与建议，不会连接你的数据库，也不直接执行任何语句。
• 所有 DDL 都建议先在测试环境验证；大表加索引请使用在线 DDL 方案。
• 数据量未知时，方案会分别标注"百万级以下"和"千万级以上"两档建议。
• 如果贴出来的 SQL 中带有手机号、身份证等敏感字面量，请先脱敏再讨论。
• 拿不准的结论会明确标注"需要 EXPLAIN ANALYZE 实测确认"。