线上系统运行期间，MySQL慢查询突然增多，接口响应随之延长，应用连接池逼近上限，数据库CPU也开始升高。群里很快冒出各种判断：数据库配置是否不足？是否需要扩容？要不要先重启应用？连接数是否应该调大？
这些操作有些能够缓解压力，有些却可能进一步放大问题。慢查询激增的原因，可能是某条SQL的访问路径变差，也可能是索引未命中、长事务阻塞后续请求，或缓存失效使流量直接进入数据库，还可能与新上线的代码、定时任务和活动流量有关。
处理此类问题，排查顺序最为关键。顺序正确，十几分钟即可缩小范围；若顺序混乱，就容易在大量指标之间反复切换，最终只能依赖经验猜测。

首先确认影响范围

发现慢查询后，应先确认业务受到的影响，而非立即调整数据库。
先确认变慢的接口范围：是全部业务受到影响，还是问题集中在订单列表、报表查询、库存扣减、用户搜索这几个接口。随后判断慢请求属于读还是写，压力位于主库还是从库，并检查是否同时存在主从延迟、连接池等待与接口超时。
若只有报表查询速度下降，应优先排查大范围扫描、排序、分组或分页。
若下单、支付、库存等写入链路变慢，排查重点应放在锁等待、长事务及主库写压力上。
若用户侧接口保持正常，仅后台任务变慢，可先限制任务的执行速度，防止后台任务继续争抢数据库资源。
此时不要急于增大连接数，因为连接数量增加并不等于数据库处理能力提高。SQL执行缓慢时，更多连接只会延长排队时间，还可能进一步加剧CPU、IO与锁竞争。

梳理一条时间线

故障现场看到的指标，往往已经是连锁反应之后的状态。慢查询、CPU、连接数、接口超时可能都在升高，但它们不一定同时开始。
排查时建议先把时间线拼出来：慢查询从几点开始增加，哪个接口先变慢，应用连接池什么时候告警，数据库CPU和IO什么时候升高，最近一次发布或配置调整在什么时候，定时任务是否刚好启动。
比如慢查询在10:03开始明显增加，10:05接口耗时升高，10:07连接池告警，10:10 MQ消费延迟。这条线说明数据库访问很可能是早期异常点。
如果应用线程先堆积，随后数据库慢查询增加，就要回到应用层看是否有线程池耗尽、下游接口超时、连接释放慢等问题。
时间线可以从监控曲线、慢日志、应用日志、发布平台、任务调度平台里拼出来。不需要做得很复杂，先把关键节点按分钟排出来，排查方向会清楚很多。

定位最可疑的SQL

慢查询日志里可能有很多SQL。故障现场没时间逐条分析，先挑对系统影响最大的SQL。
可以优先看两类：一类是单次执行时间变长的SQL，另一类是调用次数突然变多的SQL。前者可能是执行计划、索引、锁等待出了问题；后者单次可能不算夸张，但高频执行后会把数据库压住。
慢日志里有几个字段很值得看。query_time 表示执行耗时，rows_examined 表示扫描行数，rows_sent 表示返回行数。如果扫描几十万行，最后只返回几十行，这条SQL就很可疑。它可能没走到合适索引，也可能条件写法让索引用不上。
还有一类SQL平时不显眼，业务量一上来就暴露问题。比如用户列表带多个筛选条件，测试环境只有几万条数据，生产有几千万条数据；再加一个排序字段或模糊搜索，执行时间可能从几十毫秒变成几秒。
找SQL时不要只看最慢的一条，也要看总耗时。某条SQL单次500毫秒，每分钟执行几万次，对数据库的压力可能比一条偶发10秒的SQL更大。

结合数据量分析执行计划

定位到可疑SQL后，需要继续检查执行计划。这里常见的误判是：只要执行计划显示使用了索引，就认定问题与SQL无关。
索引被使用，并不意味着使用方式合理。联合索引字段次序不匹配、过滤条件选择性较差、范围查询位于前部、排序字段未包含在索引中，都可能造成数据库大量扫描。隐式类型转换也需注意，例如字段为字符串而查询条件传入数字，同样可能影响索引使用。
排查重点包括访问类型、实际使用的索引、预估扫描行数，以及是否产生临时表和文件排序。order by、group by、大分页与复杂关联都容易推高执行成本。
以常见场景为例：某订单查询SQL原先依据用户ID和状态过滤，之后增加了按创建时间倒序分页。开发环境数据较少，问题并不明显；生产环境中同一用户的订单量较大，分页位置越靠后，查询速度就越慢。解决该问题未必需要增加机器，更可能要调整索引、限制分页深度，或改用基于游标的查询方式。
执行计划只能提供线索，判断时还需综合表数据量、字段分布和业务调用频率。

锁等待与长事务容易被忽略

慢查询突然增多时，不能只关注SELECT；有时SQL并不复杂，耗时却来自持续等待锁。
例如，某批量更新任务开启事务后长期没有提交，占用了一批记录锁。后续更新请求只能排队，应用侧会出现接口变慢和连接池耗尽，数据库中则能看到大量会话停留在等待状态。
部分后台任务还会在业务高峰执行批量删除、批量更新或DDL操作。任务单独运行可能没有问题，但放在高峰期便会影响在线交易。
排查时应检查当前事务、锁等待、活跃会话，并确认是否存在长时间未提交的事务。若确定某个任务造成阻塞，处理前必须与业务方核实影响。订单、支付、账务、库存等场景尤其需要谨慎，不能只为恢复指标便随意终止会话。
面对锁问题，通常应先处理阻塞源，而不是立即优化SQL；可采取暂停任务、回滚异常发布或临时迁走部分流量等止血动作。

缓存失效可能拖垮MySQL

不少MySQL慢查询激增的问题，实际根源位于缓存层。
某个热点接口平时主要由Redis承接请求，数据库压力较低。一次发布后，如果缓存key规则发生变化，或大量热点key同时过期，请求便会绕过缓存直接查询数据库，导致MySQL流量突然增加，慢查询随之增多，应用连接池也会受到拖累。
若此类问题只围绕MySQL排查，很容易走弯路。需要同步检查Redis命中率、热点key的变化、缓存过期策略、是否存在缓存穿透请求，以及应用有没有进入降级逻辑。
处理措施也不能局限于数据库。恢复缓存、预热热点数据、临时限流或降级非核心查询，可能是更快的办法。流量恢复正常后，再补充互斥加载、打散过期时间、监控热点key等缓存保护策略。

重点核查近期变更

线上问题看似“突然”发生，线索通常可以从变更中找到。代码发布、SQL修改、索引调整、报表上线、任务调度变化、缓存策略调整以及活动流量进入，都可能引发慢查询激增。
一个典型案例是：某业务增加了新的筛选条件，接口逻辑只多拼接一个字段。测试环境查询速度很快，生产发布后慢查询却迅速增加。最终发现，新条件改变了原有索引的匹配方式，使数据库扫描行数由几千上升至几十万。代码层面的改动虽小，对数据库的影响却很大。
因此，应将发布记录与慢查询出现的时间点对齐。两者若高度重合，就优先检查本次变更涉及的SQL、接口和缓存逻辑；能够回滚的先评估回滚，可以关闭开关的先关闭开关。故障期间，不要坚持在线上猜测并修改复杂SQL。

处理次序：先止血，再治理

慢查询激增时，现场工作的目标是尽快恢复业务稳定。长期优化留到故障结束后开展，现场应先控制影响范围。
常用止血措施包括限制问题接口的流量、暂停报表与批处理任务、回滚近期发布、关闭新增查询入口、恢复缓存、处理异常锁等待，以及临时将部分读请求迁往只读实例。
添加索引需要选择合适时机，因为大表在线加索引可能产生额外压力，高峰期尤其如此。没有把握时，可先采取降级或限流，待业务低峰再处理。扩容也要区分具体场景：长期容量不足时扩容有价值；若问题是一条SQL高频扫描大表，扩容只能短暂缓解。
故障恢复后，应转入长期治理：核心SQL上线前检查执行计划，规范大表查询，按业务模块划分慢SQL归属，为定时任务增加限速与告警，尽量隔离报表库和交易库，保护缓存热点数据，并为数据库连接池设置合理上限。
这些措施本身并不复杂，却需要持续落实。慢查询很少能够一次彻底清除，业务发生变化后仍可能再次出现。

企业现场应开展日常巡检

在企业环境里，MySQL慢查询暴增往往不是孤立事件。很多系统长期缺少慢SQL治理，平时只在故障后查几条日志，业务恢复后就停下来了。等数据量继续增长，或者新功能上线，类似问题还会再出现。
据我了解，江苏立维运维服务在数据库运维、云运维、驻场运维和7×24保障中处理过不少这类场景。他们通常不会只看数据库CPU或慢日志，而是把应用接口、连接池、Redis命中率、任务调度、发布记录放在一起分析，先判断压力从哪里传来，再决定止血动作。
这类服务更适合放在日常。比如定期做MySQL健康巡检，梳理慢SQL排行，检查索引缺失和冗余，评估备份恢复可用性，完善告警阈值和应急预案。
MySQL慢查询突然暴增，排查时别被告警带着跑。先确认影响范围，再拉时间线，然后看可疑SQL、执行计划、锁等待、缓存和近期变更。
线上处理要先稳住业务，再做SQL、索引、架构和流程层面的治理。慢查询表面发生在数据库，背后常常连着代码习惯、业务流量、缓存策略和运维流程。
排查顺序清楚，现场就不会乱。平时把巡检、告警和SQL治理做好，遇到问题时才有判断依据。