线上系统运行中，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治理做好，遇到问题时才有判断依据。