线上出现一批慢 SQL，把数据库连接池打满了，你会如何止损、定位和验证优化结果？
我的判断
连接池被慢 SQL 打满时先限流和终止失控查询恢复服务，同时保留参数、计划和锁现场，再针对真正瓶颈优化。
先从链路拆出连接池等待和数据库执行时间。如果大量请求只是等连接，继续扩应用实例会制造更多数据库连接。止损会限制问题接口并发、暂停报表或批任务、缩小查询时间范围；对确认安全且失控的只读查询执行 KILL QUERY，必要时把非核心读切到有余量的副本。
现场至少保留 SQL 指纹、真实参数、调用量、Rows_examined/Rows_sent、执行计划、锁等待、活跃事务和资源曲线。扫描千万行返回十行，重点是访问路径；扫描不多但 Lock_time 高，要查长事务；单条 50ms 但每秒几万次，也可能是总负载主因。
优化可能落在联合索引、游标分页、拆批、减少返回列、事务范围或数据归档。变更在真实数据分布上回放，并比较接口 P99、吞吐、扫描行数、CPU/IO 和写入成本。
把连接池调大通常只是让更多请求同时压向已经饱和的数据库，不是第一修复动作。
容易答偏踩坑误区
- 线上直接跑高成本 EXPLAIN ANALYZE。 它会真实执行，应先评估或在副本验证。
- 只优化最慢的一条。 高频中慢 SQL 可能消耗更多总资源。
- 只看 SQL，不看锁和连接等待。 数据库执行快也可能接口等待很久。