慢SQL急诊医生

慢查询排查的“急诊室”

在日常开发中，遇到 EXPLAIN 输出中满屏的 type: ALL、Extra: Using filesort 或是突增的 rows 估算值，往往让人无从下手。更令人头疼的是那些“间歇性变慢”的查询，背后可能隐藏着锁等待、长事务或间隙锁。对于兼任 DBA 的后端工程师来说，如何快速定位根因，并给出能直接上线的索引与重写方案，是一项耗时且极易出错的工程挑战。

核心能力与诊断工作流

Slow SQL ER Doctor 摒弃了冗长的理论说教，采用“先诊断，后开方”的急诊模式，直接交付可执行的 CREATE INDEX 语句和重写后的 SQL。

• 执行计划逐行解读：逐列剖析 EXPLAIN 或 EXPLAIN ANALYZE 输出，精准定位导致性能瓶颈的具体执行步骤。
• 索引与查询处方：基于最左前缀原则和选择性评估生成索引，同时消灭 SELECT *、隐式类型转换及包裹索引列的函数；将深分页改写为 keyset/cursor 分页或延迟连接。
• 锁与慢日志分诊：识别间歇性慢查询的锁等待特征，提供精确的诊断命令；对大段慢日志输出基于“频率 x 延迟”的 Top 5 优先级列表。

其工作流高度结构化：首先收集慢 SQL 与执行计划，随后诊断全表扫描等异常并排序根因。接着提供 1 到 3 个按“预期收益 x 实现成本”排序的优化选项，每个选项均附带可执行语句。最后给出修复后的执行计划预期及验证查询，并附带完整的发布前风险检查清单。

适用边界与安全护栏

作为纯咨询型技能，它不会连接或执行任何针对你数据库的写操作。所有索引方案均会明确说明其服务的条件、是否为覆盖索引以及写路径成本。若数据量未知，它会分别提供百万行以内和千万行以上的两档建议，并在不确定时提醒使用 EXPLAIN ANALYZE 进行实测验证，而非盲目承诺“10倍提速”。

此外，它严格遵循安全规范：在提供 DDL 前会提醒在 staging 环境测试，并建议大表使用在线 DDL 工具（如 gh-ost 或 pt-osc）。若 SQL 中包含手机号、邮箱等敏感字面量，会要求先进行脱敏处理，并根据具体的数据库版本（如 MySQL 5.7 vs 8.0）调整方案。