标准答案
- 先看调用频率、P50/P95/P99、超时率和具体参数，区分偶发长尾与高频系统性慢查询。
- 查看执行计划与实际行数，确认是否全表扫、错误 JOIN 顺序、回表过多、临时排序或统计信息失真。
- 检查锁等待、事务时长和阻塞链，很多“慢 SQL”实际是在等其他事务释放资源。
- 观察 CPU、IOPS、缓存命中、磁盘延迟、网络与连接池，判断瓶颈是否在 SQL 本身之外。
- 比较不同参数和租户的行数与耗时，识别热点 Key、低选择性条件和数据倾斜，再选择索引、改写、限流或架构方案。
题目解析
只拿一条脱敏 SQL 在本地跑很容易误判。生产慢查询依赖真实参数、缓存冷热、并发、统计信息和锁竞争，必须把 SQL 文本、绑定值、计划、等待事件和系统指标关联起来。
修复后要观察写入成本和其他查询是否退化。新增索引可能让目标查询变快，却让高写入表的延迟升高；强制索引可能对另一组参数变差。
常见误区
- 只根据 SQL 文本猜索引，不收集慢发生时的参数和执行计划。
- 修复一条查询后不做回归观察，导致写入或其他读路径被新索引拖慢。