我先给结论，再说明它在项目里解决什么问题。从发现、止损、定位、优化到复盘，掌握慢 SQL 线上处理完整 SOP。先确认影响范围并止损，再通过监控、慢查询日志、执行计划和锁等待定位根因；根据访问路径、索引、SQL 写法、事务和数据模型实施优化，最后用真实数据验证并建立长期防复发机制。 慢 SQL 处理不能上来就“加索引”。线上响应必须兼顾业务可用性、数据正确性和变更风险。

核心机制我会按一次真实执行过程来讲。先确认影响范围并止损，再通过监控、慢查询日志、执行计划和锁等待定位根因；根据访问路径、索引、SQL 写法、事务和数据模型实施优化，最后用真实数据验证并建立长期防复发机制。 慢 SQL 处理不能上来就“加索引”。线上响应必须兼顾业务可用性、数据正确性和变更风险。

实现细节只抓关键入口，不会整段背源码。performanceschema.eventsstatementssummarybydigest：按指纹聚合总成本。 sys.statementanalysis：扫描、延迟和临时表视图。

放到生产使用时，我会关注参数和验证数据。同时注入慢 SQL 与连接池等待，拆分客户端等待、锁等待和执行时间，避免误把排队当 SQL 慢。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「总耗时贡献」为主基线，记录值应满足「按指纹排序」；同时保存 SQL 指纹总耗时、连接池等待，使后续变化能够回到同一时间轴比较。

最后补充常见误区和使用边界。慢日志显示 SQL 本身执行约 80ms，但连接池等待超过 2s；根因是另一批报表查询占满连接。隔离报表池、限制并发并优化扫描后才恢复，单纯给接口 SQL 加索引没有作用。 只按耗时排序忽略调用次数：SQL 指纹总耗时：先按总成本而非单次最慢排序。 优化一条 SQL 却压垮写入：连接池等待：隔离报表连接池。 慢 SQL 排查要从请求端到数据库形成时间分解；只有证明时间花在执行器和具体节点，索引优化才是正确动作。