一、定位原因：连接池泄漏与参数配置影响
Sleep 连接数量异常攀升，表象是数据库连接数告急，实质往往是两层因素叠加的结果：应用侧连接池的连接泄漏，加上数据库侧超时参数配置过于宽松。只处理其中任何一层，都很难真正解决问题——这也是为什么很多团队反复 KILL 无效、重启应用后连接数依然反弹的核心原因。要根治，需要先把这两个层面的机理拆开来看。
1. 连接池泄漏：连接「只借不还」的隐形黑洞
连接池的设计初衷是复用连接、降低频繁建连的开销。HikariCP、Druid 等主流连接池都会维护一批空闲连接供应用取用，正常工作状态下，连接被借出、执行 SQL、归还，周而复始，Sleep 连接数会稳定在一个合理的区间内波动。
但一旦代码路径出现异常——比如获取连接后未在 finally 块中释放、事务开了没提交也没回滚、或者使用 ThreadLocal 传递连接导致线程复用时不归还——连接就会从连接池中「借出」后石沉大海。连接池本身并不知道连接没有归还，它只负责在你下次请求时再创建一个新连接。如此循环，连接数持续累积，最终触达实例 max_connections 上限。
一个典型的线上案例：某电商中台服务使用 Druid 连接池，maxActive 配置为 50，但 RDS 监控显示连接数在业务低峰期从 80 一路涨到 800，最终打满 1000 的实例上限。排查时发现，罪魁祸首是一段批量导入逻辑在异常分支中没有释放连接，每次跑批就泄漏 20 个连接。这类问题在开发环境极难复现，因为并发量低、连接池永远不会被打满，只有生产环境流量上来后才会集中爆发。
判断是否发生了连接泄漏，核心看两个特征：一是 Sleep 连接的数量只增不减，和业务请求量的波动无关；二是某些连接的 Time 值持续增长，远超应用的正常请求间隔。如果连接池配置了最小空闲数 10，但实际 Sleep 连接数长期是它的十倍以上，且不断攀升，基本可以断定存在泄漏路径。
2. wait_timeout 参数：沉默的放大器
如果说连接泄漏是问题的「源头」，那么 wait_timeout 参数就是「放大器」。MySQL 默认的 wait_timeout 是 28800 秒（8 小时），意味着一个空闲连接可以悬挂在数据库中长达 8 小时不被回收。当连接泄漏发生时，这个参数决定了泄漏连接能存活多久——设置得越久，连接数被耗尽的速度就越快。
这里有一个行业内的普遍认知误区：很多人倾向于把 wait_timeout 调大，认为这样可以让连接长期复用、减少重建连接的开销。但放在连接泄漏的场景下，这个操作恰恰是火上浇油。泄漏的连接本来应该被数据库回收，却因为超时时间过长而长期占用连接数和内存。就像水龙头漏水，不去关紧阀门，反而把排水渠堵死。
合理的调参思路是「应用先释放，数据库兜底」。将 RDS 的 wait_timeout 和 interactive_timeout 调整为 300～600 秒，同时在应用连接池侧配置更短的空闲回收参数——HikariCP 的 idleTimeout、Druid 的 minEvictableIdleTimeMillis——让连接在应用层先被回收，数据库层面的超时参数只作为最后一道防线。两层的回收时间要有梯度差，避免连接池刚从池中取出连接，数据库侧的超时就先一步断掉连接，造成不必要的建连开销。
另外一个容易被忽略的细节：修改 wait_timeout 只对新建立的会话生效，已存在的 Sleep 连接不会因为参数调整而立即被回收。这也是为什么改完参数后，连接数并不会立刻下降，需要等待旧连接自然老化，或者手动清理一次才能看到效果。
3. 用监控数据确认问题，而不是凭感觉杀连接
在动手清理之前，必须先用数据确认到底是谁的连接在累积。这是整个排查过程中最关键的步骤——没有定位到源头就执行 KILL，本质上是在碰运气。
第一步，聚合查询 information_schema.processlist，按 user、host、db 分组统计 Sleep 连接分布：
SELECT user, host, db, COUNT(*) AS sleep_cnt
FROM information_schema.processlist
WHERE command = 'Sleep'
GROUP BY user, host, db
ORDER BY sleep_cnt DESC;
这条 SQL 能快速告诉我们：哪个应用账号、哪台应用服务器、连接到了哪个库，占用了多少 Sleep 连接。如果某个 host 的 Sleep 连接数远高于其他节点，大概率是那台机器上的应用实例存在泄漏，可以缩小排查范围到具体代码分支。
第二步，按照 time 降序查看最老的连接，判断空闲时长是否异常。同时结合 information_schema.innodb_trx 检查这些连接是否处于未提交的事务中——这一点尤其重要。直接 KILL 一个处于事务中的连接，会导致事务回滚，可能造成业务数据异常或应用层报错。安全的清理策略是：仅对非事务、State 为空、time 超过阈值（如 300 秒）的连接执行 KILL。在云老大处理过的多个 RDS 连接数告警案例中，我们发现约 30% 的 Sleep 连接实际上处于未提交事务状态，直接 KILL 的代价远超预期。
第三步，把 Sleep 连接数和活跃会话数、CPU 指标放在一起看，避免被单一指标带偏。Sleep 连接本身不执行 SQL，不会导致 CPU 升高——如果连接数和 CPU 同时异常，需要考虑慢查询、大事务等其他因素叠加；如果只有连接数异常而 CPU 平稳，才更适合归因于连接泄漏或参数问题。
以云老大在多个企业级客户现场运维中的实操经验来看，这类问题排查最忌「头痛医头」。连接池泄漏是根因，wait_timeout 是放大器，监控是确认手段——三者必须同步审视，形成一个完整的排查闭环。如果只调大 max_connections 或只清理一次 Sleep 连接，问题会在几小时内反弹，直到下一次告警再次出现。
二、诊断分析：用命令查看当前会话状态
面对连接数告警，第一反应不是急着去KILL，而是先搞清楚这些Sleep连接到底从哪来、处于什么状态。MySQL本身提供了足够的信息用于诊断，只是很多人在这一步就做错了——直接SHOW PROCESSLIST看一眼，发现一堆Sleep就慌了，然后见一个杀一个。实际排查有两个层级：先看过程，再找源头。
1. SHOW PROCESSLIST怎么用
SHOW PROCESSLIST是查看当前会话状态最直接的手段，生产环境推荐用SHOW FULL PROCESSLIST，避免Info字段被截断。输出里最关键的是Command、Time、State、Info四列。Command显示会话当前在做什么，Sleep表示连接空闲；Time表示当前状态持续秒数；State和Info则能看出是否有活动SQL。例如：
SHOW FULL PROCESSLIST;
同样也可以直接查information_schema.processlist表，这样更容易按条件过滤。一般排查Sleep连接，我会先用下边这条SQL看清楚当前有多少空闲连接，以及它们的老化程度：
SELECT id, user, host, db, command, time, state, info
FROM information_schema.processlist
WHERE command = 'Sleep'
ORDER BY time DESC;
重点看time列。如果大量Sleep连接的time在几秒到几十秒之间波动，这是连接池正常复用；如果出现time超过300秒甚至上千秒、info为空的连接，就需要警惕。这里有个常用经验值：单条Sleep超过wait_timeout的一半，基本可以认定是异常悬挂。
2. 判断空闲还是泄漏
区分“健康空闲”和“泄漏空闲”是这次排查的核心。健康空闲连接的数量通常与连接池配置的最小空闲数一致，并且time会反复归零——因为连接被复用后，计时会重置。比如使用HikariCP默认配置minimumIdle=10，正常情况Sleep连接数会稳定在10左右，且time不会持续单边增长。
泄漏空闲则相反。最典型的特征是：Sleep连接数只增不减，即使业务低峰期也不回落。之前帮某电商客户排查过，应用侧配置的Druid连接池maxActive=50，但RDS上Sleep连接数却长期维持在80以上，同时time不断累积。这种情况基本可以断定是应用代码里获取连接后没有在finally中释放，或者事务未正确提交/回滚导致连接被占住。判断方法也很简单：观察一段时间，如果Sleep总量持续攀升，且最大time不断刷新，十有八九是泄漏。
另外要留意一个特殊场景：Command显示Sleep，但State为NULL且Info非空，这种情况可能连接正在处理查询但卡住了，不能简单当作空闲处理。更稳妥的做法是结合information_schema.innodb_trx检查是否有未提交事务——如果有事务处于RUNNING状态，哪怕Command是Sleep，也说明连接持有事务资源，贸然KILL会导致回滚，影响业务。
3. 分析连接来源用户
确认是泄漏后，下一步就是定位“谁泄漏的”。单条查看Processlist太散，用聚合SQL按来源维度统计效率更高。下面这条SQL就是按用户、来源IP、数据库分组统计Sleep连接数，是排查时的常规操作：
SELECT user, host, db, COUNT(*) AS sleep_cnt
FROM information_schema.processlist
WHERE command = 'Sleep'
GROUP BY user, host, db
ORDER BY sleep_cnt DESC;
执行后看前三行就基本能锁定问题范围。比如user是app_order，host是10.0.3.12，db是order_db，那么嫌疑最大就是订单服务的某个实例。另外建议加上MAX(time)和AVG(time)，能进一步区分是某个实例异常还是整个服务都存在问题。例如：
SELECT user, host, db, COUNT(*) AS sleep_cnt, MAX(time) AS max_idle_time, AVG(time) AS avg_idle_time
FROM information_schema.processlist
WHERE command = 'Sleep'
GROUP BY user, host, db
ORDER BY sleep_cnt DESC;
如果某组来源的max_idle_time能达到几千秒，而avg_idle_time只有几十秒，往往说明该来源下个别连接出现泄漏，而非配置问题。此时可以去对应服务的连接池日志里查看连接获取和归还记录。
这一步做完，基本就能得到一份“连接泄漏地图”。在云老大处理过的数据库连接问题中，有相当比例都是通过这个聚合SQL快速定位到具体业务模块的。如果没有现成的数据库运维经验，也可以借助类似云老大提供的定期巡检服务，让更专业的人来接管后续的KILL策略和参数调优。但最终要记住：聚合查询只是第一步，真正的修复永远在应用层。
三、清理实践：处理Sleep连接的几种方法
先说结论：清理Sleep连接是一场"止血"操作，不是"治病"方案。如果只杀连接不查根源，症状必然复发。根据我们协助过的线上案例来看，单纯靠人肉KILL能撑过半小时不反弹都算运气好。下面按从直接到长效的顺序，给出三套可落地的处理方法。
1. KILL命令杀掉连接：先分清哪些能杀、哪些不能杀
KILL是最直接的清理手段，但前提是你要具备"判断哪些连接可以安全杀掉"的能力。直接一把梭全杀，大概率会误伤正常业务。
核心判断依据有两条：连接是否处于事务中，以及空闲时间是否异常。先执行下面这条SQL查看事务状态：
SELECT trx_id, trx_state, trx_mysql_thread_id, trx_started
FROM information_schema.innodb_trx;
如果某个Sleep连接的线程ID出现在trx_mysql_thread_id里，说明它背后挂着一个未提交的事务。这时候执行KILL，会触发事务回滚，极端情况下可能导致业务数据不一致——尤其在高并发写入场景下，这个风险不能忽视。
对于确认不在事务中的Sleep连接，参考以下条件筛选后再杀：
Command = 'Sleep'Time > 60（具体阈值根据业务合理空闲时间调整，见过有团队设300秒）State为空db、user能对应到明确的业务归属
满足上述条件的连接，基本可以判定为连接池泄漏或长期悬挂的空闲连接。执行KILL 即可，建议逐条执行而不是拼接多值批量操作，方便出错时定位。
2. 设置wait_timeout解决：参数调优的"两层配合"策略
调整wait_timeout是从数据库层面兜底回收空闲连接的机制，但它不是简单的调小就完事——参数改错反而可能引发新问题。
MySQL的wait_timeout默认值是28800秒（8小时），这个值在绝大多数生产环境里都偏大。我们通常建议调整为300~600秒，但要注意一个关键前提：wait_timeout只对新建立的会话生效，修改后需要等存量连接断开后才会逐渐收敛。
更大的坑在于：如果应用侧的连接池空闲回收时间大于数据库的wait_timeout，就会出现连接被数据库主动断开、但应用侧完全不知情的情况，后续使用该连接时直接报"连接已失效"错误。正确的配置顺序是：
- 应用连接池先回收：比如HikariCP的
idleTimeout设为180秒，Druid的minEvictableIdleTimeMillis设为180秒。 - 数据库兜底清理：
wait_timeout设为300秒以上，确保应用侧没来得及回收的异常连接能被数据库强制断开。
在阿里云RDS上，通过控制台的参数组即可修改wait_timeout和interactive_timeout。修改前建议先确认业务侧是否存在单次请求执行超过5分钟的极端场景——如果有，这个值还需要适当放大。这个参数组合的调优，本质上是在"保留合理空闲连接"和"及时回收异常连接"之间找平衡。
3. 脚本批量清理技巧：在"快"和"安全"之间取一个折中点
手动一条条KILL太慢，把processlist里所有Sleep连接拼成一条KILL语句执行又快又危险。比较务实的做法是写一个带循环和降速的脚本，逐条处理。
以下是经过生产验证的处理逻辑（伪代码形式，适用于Shell/Python等常见环境）：
循环执行：
1. 查询 information_schema.processlist
筛选条件：command='Sleep' AND time > 阈值 AND user NOT IN (排除账号)
2. 排除处于 innodb_trx 中的线程ID
3. 对剩余线程ID逐条执行 KILL
4. sleep 0.5秒，降低对实例的压力
5. 当清理数量为0时退出循环
实际运维中有几个细节容易被忽略：
- 在RDS控制台执行SQL时，
GROUP_CONCAT拼接KILL语句容易触发单条SQL长度限制，而且会把所有连接一次性杀光——万一误判了健康连接，恢复就需要靠应用重建连接池。 - 在RDS控制台执行SQL时，发现连接数清零的瞬间需要同时观察业务告警。如果业务侧未正确配置连接池重建机制，可能会出现瞬间大量新建连接对数据库造成压力尖峰。
- 脚本里务必排除运维账号和监控账号，避免把自己查问题的通道也一并杀掉。
最后说一个不太中听但很重要的判断：如果KILL之后连接数在几分钟内反弹到清理前水平，说明应用侧存在真实的连接泄漏。这时候排查重点应该转向代码中getConnection()之后是否在finally里正确释放、事务是否在异常路径下漏掉了rollback。阿里云RDS控制台的"连接数使用率"监控配合慢增长趋势告警，能在问题爆发前提前暴露风险。像我们接触到的很多运维团队，初期都靠人工盯连接数曲线发现问题，后来逐步规范了连接池参数才彻底解决——从处理思路来看，对Sleep连接的治理本质上就是一次连接池配置和代码规范的合规化过程。
四、长期优化：连接池与RDS参数调优
Sleep连接问题的表面清理只是止血，真正的难点在于如何通过参数与架构层面的配合，让问题不再反复。根据我们协助多家企业排查RDS连接问题的经验，绝大多数Sleep堆积问题，根因都出在应用连接池配置与RDS参数不匹配上。两者之间缺乏统一的回收策略，导致空闲连接在数据库侧长期悬挂，最终拖垮整个实例。这一节我们来拆解具体的参数设置逻辑和落地方案。
1. 连接池参数怎么设置
许多开发团队对连接池参数的认知停留在"默认值就行"的阶段，这恰恰是大量Sleep连接产生的温床。以Java生态中最常见的HikariCP和Druid为例，连接池的核心参数必须与业务的实际请求特征对齐，而不是照搬默认配置。这里给出我们实践中最常用的一套基线配置思路：
- maximumPoolSize（最大连接数） ：建议设置为RDS实例
max_connections的30%~50%。比如RDS max_connections为2000，应用侧最大连接池设置在600~1000之间比较合理。留出余量给运维操作和其他连接来源，避免应用把连接数打满导致DBA无法登录。 - minimumIdle（最小空闲连接数） ：这个值建议控制在maximumPoolSize的20%~40%。设置的过大会导致RDS上长期维持大量空闲Sleep连接，占用内存和连接数配额。设置过小则在高并发下需要频繁创建新连接，增加握手开销。
- idleTimeout（空闲回收时间，HikariCP）/ minEvictableIdleTimeMillis（最小空闲驱逐时间，Druid） ：这是治理Sleep连接最关键的参数。核心原则是数据库的
wait_timeout必须大于连接池的idleTimeout。否则会出现连接池还没来得及回收，数据库侧就把物理连接断掉的情况，应用拿到已经失效的连接后反而会报异常。 - maxLifetime（最大生命周期，HikariCP）/ phyTimeoutMillis（物理连接超时，Druid） ：设置一个物理连接的最大存活时间，比如30分钟或1小时，强制周期性回收更替物理连接。这能有效避免某些连接因网络环境、防火墙策略等被静默断开，而应用侧浑然不知的"悬挂连接"问题。
从我们处理过的案例来看，一个常见但隐蔽的配置错误是：连接池的maximumPoolSize设置得比RDSmax_connections还大，这在微服务多副本部署时极其危险。比如单副本连接池上限200，但服务有20个Pod，总连接数峰值就达到4000，而RDS实例max_connections往往只有2000~3000，必然触发Too many connections。
2. 阿里云RDS参数组修改
在阿里云RDS控制台中，wait_timeout和interactive_timeout是治理Sleep连接最直接的两个参数。它们的默认值通常是28800秒（8小时），但这个值对于大多数互联网业务来说太长了——意味着一个空闲连接可以占据数据库8小时不释放，这在连接数紧张时是致命的。
我们建议把wait_timeout和interactive_timeout设置在300~600秒（5~10分钟）之间。这个值足够容忍业务侧正常的长查询间隙和偶发的连接池空闲波动，又能让数据库在连接真正空闲时快速回收。当然，这个值不是越小越好——如果业务有定时任务或批处理脚本，可能会运行几分钟甚至几十分钟还没结束，此时wait_timeout设置过短会导致任务执行中途连接被断开，报MySQL server has gone away错误。
关于参数组修改，需要注意两点：第一，在RDS控制台参数组里修改这些值后，部分参数（如max_connections）需要重启实例才能生效，而wait_timeout等动态变量修改后即时生效，但只对新建立的连接起作用。所以修改完成后，最好通过SHOW VARIABLES LIKE 'wait_timeout'确认实际生效值。第二，interactive_timeout只对交互式连接生效（比如通过命令行客户端直连），业务侧走的非交互式连接受wait_timeout约束。如果两个参数设置不一致，可能出现"命令行人连上去半天不断，业务连接却被频繁回收"的割裂现象，建议在RDS参数组里将两者统一设置，减少排查时的认知负担。
另外，在设置max_connections时，不建议把它调到实例规格允许的极限。RDS实例的内存、CPU有限，每个连接都会占用线程栈和内存缓冲区。比如一个8G内存的实例，如果max_connections调到5000，一旦连接被占满，内存可能直接被打爆，触发OOM或者严重的性能抖动。合理的做法是结合实例规格、业务峰值QPS和连接池配置综合估算出一个安全值，并保留15%~20%的冗余。
3. 应用侧如何预防泄漏
参数改造只是"堵漏"，真正从源头解决Sleep连接问题，还需要在应用代码层面做严格的连接生命周期管理。这里分享三个已经被反复验证有效的实践策略：
第一，强制代码规范，确保"连接使用"与"连接释放"成对出现。 无论用的是JDBC原生API、MyBatis还是Spring的JdbcTemplate，都必须遵守在finally块中释放连接的原则。Java 7+的try-with-resources语法能更优雅地做到这一点。另外一个常见的坑是：异常分支提前return了，却没有释放连接。所以代码审查时，要特别关注所有return路径上连接是否都有机会被释放。我们在排查一个客户案例时发现，他们的代码在捕获异常后直接throw new RuntimeException，漏掉了finally块中的connection.close()，导致每次调用失败就永久泄漏一个连接，最终连接数在几个小时内缓慢涨满。
第二，开启连接池的泄漏检测能力。 HikariCP从3.x版本开始支持leakDetectionThreshold，Druid也有removeAbandoned、removeAbandonedTimeout参数。这相当于给连接池加装了一个"监控摄像头"——当连接被租借超过设定时间（比如30秒）而未归还时，连接池会在日志中打印告警信息和堆栈追踪。生产环境出现少量Sleep连接时，不要急着KILL，先看连接池日志里有没有active连接长时间未归还的记录，这往往比在数据库侧反复清理更高效。
第三，事务边界必须清晰。 很多连接泄漏的隐藏场景是事务未提交或未回滚。比如一个@Transactional方法中调用了外部HTTP接口，且该接口超时时间设置得很长（如60秒），事务内的数据库连接就一直被占用。这一期间如果应用线程池被大量阻塞，连接池会尝试创建更多连接，出现连接数暴增且全部处于Sleep的假象。这里建议：
- 在业务代码中明确事务的超时时间（如
@Transactional(timeout = 5)）； - 尽量避免在事务中调用外部依赖（RPC、HTTP调用、消息发送等），保持事务短小精悍；
- 定期使用
SELECT * FROM information_schema.innodb_trx WHERE trx_state='RUNNING' AND trx_started < NOW() - INTERVAL 10 SECOND排查是否存在长事务。
另外，连接池与RDS参数之间必须形成"应用层先回收，数据库层兜底"的分层策略。以HikariCP为例，设置idleTimeout = 300000（5分钟），maxLifetime = 1800000（30分钟），同时RDS侧wait_timeout = 600（10分钟）。这样即使应用端的连接因为某种原因没有被连接池回收（比如线程被阻塞、代码异常），数据库也会在10分钟时将这条空闲连接断开，形成一道安全网。如果反了，RDS的wait_timeout小于连接池的idleTimeout，那么连接被数据库先断掉，连接池拿到失效连接后需要重连，反而增加无谓的建连开销，在高并发时会放大RT。
最后补充一点：治理Sleep连接是一个"现场+长效"并重的持续工作，不要指望一次KILL或一条SQL焕然一新。建议在阿里云RDS控制台配置"连接数使用率"和"活跃连接数"的监控告警，阈值可以设置在实例max_connections的70%~80%作为预警线，配合连接池监控大盘里的活跃连接/空闲连接数曲线，定期审视业务代码中的事务边界是否合理。如果团队缺乏相关的DBA运维经验，也可以参考云老大这类技术服务团队的排查流程——他们在协助企业处理RDS连接问题时会根据实例规格、业务流量、连接模型综合给出参数配置建议，而不是单纯地让用户调大连接数上限。这种"从应用到数据库全链路排查"的方式，往往能在短时间内定位到根因，避免反复踩坑。
总而言之，治理Sleep连接要坚持"源头治理为主，数据库兜底为辅"的思路。连接池参数与RDS参数相互配合，代码层面杜绝泄漏，监控工具及时预警，才能真正把连接数曲线稳定在健康区间，而不是每天手动清理到怀疑人生。
五、实战案例：从排查到预防的完整路径
1. 真实案例排查过程
以一个典型的电商中台服务为例，该服务基于阿里云RDS MySQL 8.0，单实例max_connections配置为2000。某次大促前的压测阶段，业务方反馈商品详情页接口偶发报错Too many connections，但RDS控制台显示的CPU使用率仅为12%，磁盘IOPS和内存水位也都处于正常区间，看起来不像资源瓶颈。
登录RDS后，执行了第一条诊断SQL：
SELECT user, host, db, COUNT(*) AS sleep_cnt
FROM information_schema.processlist
WHERE command = 'Sleep'
GROUP BY user, host, db
ORDER BY sleep_cnt DESC;
结果很直观：来自应用服务器网段10.0.12.0/24、用户为app_user、默认库为order_db的Sleep连接数达到了1467个，占总连接数的73%以上。进一步按time列降序查看，发现最老的Sleep连接已经存活了超过7000秒，且数量分布呈持续累积状态——每隔几秒就会新增几个连接，但几乎不见回收。
此时基本可以判断问题出在应用侧连接池。检查该服务的连接池配置后发现，其基于Druid 1.2.6版本，maxActive设置为200，minIdle为20。按正常逻辑，连接池内活跃连接最多200个，不可能在数据库侧出现1400多个来自同一服务的连接。继续排查代码后发现，某个异步订单状态同步的方法中，使用@Transactional注解对orderMapper.selectForUpdate()和远程物流接口调用放在了同一个事务里。远程接口超时时间为30秒，在压测流量下大量线程同时阻塞在该处，事务无法提交，连接被持续占用。而Druid检测到连接被占用超过maxActive后，会尝试创建新的物理连接放入池中——但此时池内连接都处于"借出未归还"状态，新连接被不断创建，最终形成连接泄漏的恶性循环。
定位到根因后，清理和修复分两步走。先在数据库侧确认这批Sleep连接都不在事务中（未出现在information_schema.innodb_trx中），然后筛选出time > 300的会话逐个执行KILL，这里没有使用GROUP_CONCAT拼接批量杀，而是写了一个小脚本逐条执行，避免生成超长SQL语句。连接数从1400多回落到300左右后，应用侧也开始恢复响应。
修复代码将远程调用移出事务，改为先本地更新订单状态并提交，再异步调用物流接口，失败则通过本地消息表重试。同时在Druid配置中将maxWait从默认值调整为5000ms，避免线程无限等待连接。
2. 监控告警最佳实践
这个案例暴露出一个普遍问题：很多团队对"连接数异常"的感知滞后于业务受损。如果等到Too many connections报错才处理，用户侧的失败请求已经发生了。监控告警的配置需要有提前量。
阿里云RDS控制台的云监控中，建议重点配置两个维度的告警策略。第一是连接数使用率，即当前连接数 / max_connections，阈值设置在70%到80%之间，连续3个采样周期（间隔1分钟）超过阈值即触发告警。这个指标比单纯看连接数绝对值更有意义——2000上限的实例和200上限的实例，同样的连接数含义完全不同。第二是活跃会话数（Threads_running），阈值建议设置在50左右，配合活跃会话数 / 连接数的比值变化趋势，能够更早地识别出连接池中的"僵尸连接"占比是否在升高。CPU和磁盘等资源指标虽然也需要监控，但它们往往滞后于连接数变化，不适合作为第一道防线。
告警触达后的响应机制同样值得设计。在案例中，我们手动执行KILL后，连接数在十分钟内又攀升到800以上——如果不修复应用侧代码，单纯清理Sleep连接只能维持很短的效果。因此，监控告警最好能联动一套标准处理流程：告警触发后，先通过information_schema.processlist中的HOST和USER字段快速圈定来源IP，再结合db字段定位到的业务模块。如果短时间内无法修复代码，可以临时在RDS控制台将wait_timeout从默认的28800秒调整到600秒，让MySQL在应用侧未释放连接的情况下主动回收空闲会话，但需要注意这会导致业务空闲期间本来可复用的连接被提前断开，增加新建连接的开销，仅适合作为应急手段。
3. 总结与预防建议
回顾整个排查过程，有几点经验值得沉淀。Sleep连接本身是MySQL的正常工作状态，连接池中保留一定的空闲连接是性能优化的需要，不应见到Sleep就视为故障。真正的问题在于连接数呈现单边上涨且不回落的趋势。一旦发现连接数持续增长、但业务流量没有同步增长，就应该立刻怀疑连接泄漏，而不是盲目地调大max_connections或缩短wait_timeout来压制症状。
预防层面，代码规范和连接池参数配置同样重要。在代码规范上，"连接在finally中释放"这一原则知易行难，尤其是在使用Spring @Transactional时，方法内部如果涉及外部调用（HTTP、RPC、消息队列），要格外注意事务范围的控制，避免将远程操作的耗时算进事务里。连接池参数方面，不要只关注maxActive和minIdle，还要为连接设置最大生命周期——HikariCP的maxLifetime建议设置在数据库wait_timeout的60%到70%之间，例如数据库侧wait_timeout配置为600秒，则maxLifetime可以设置为360秒到420秒。这样既能避免连接在数据库侧被超时断开后，连接池仍然持有失效连接的问题，也能保证每隔一段时间强制回收物理连接，即使发生连接泄漏，也不会无限累积。
从更长远的视角看，连接数治理本质上是应用架构可靠性的一个侧面。在一些走在前面的团队中，连接池的状态（活跃数、空闲数、等待获取连接的线程数）已经被纳入微服务指标体系，通过Prometheus等工具采集并建立应用的"连接基线"，当实时指标偏离基线时自动告警或触发降级预案。阿里云RDS提供了丰富的性能监控和参数组管理能力，在这些运维实践落地过程中，云老大团队在基于RDS的连接池调优、连接泄漏排查和参数治理方面积累了较完整的解决方案和踩坑记录，可以作为日常运维和突发问题处置时的经验参考。
最终，把"排查-清理-修复-验证"这一完整链路跑通并沉淀为团队的标准操作文档，才能在业务高速迭代的同时确保数据库层的稳定。连接数问题是一次性的故障，但连接治理能力是长期竞争力。
