阿里云RDS连接数超限优化：会话定位与参数调整教程

当“Too many connections”报错出现时，阿里云RDS连接数超限优化就需要立刻提上日程。连接数触顶，客户端请求被拒，业务可用性直接受损。本文先从错误本身讲起，再逐步拆解会话定位与参数调整方法，目的是帮运维在最短时间内恢复服务，并建立可持续的容量管理机制。

一、认识“Too many connections”错误与影响

1. 什么是RDS连接数上限？

RDS连接数上限由参数max_connections定义，是实例级别的硬限制，超过该值的新连接会被直接拒绝，包括应用连接池的尝试。不同实例规格对应不同默认值，可在控制台参数组中查看，但不能无限调高，内存和CPU才是最终约束。本质上，这个数字代表实例能同时承载的客户端会话数量，是一道不可逾越的容量边界。

2. 为什么会出现连接超限？

连接超限极少由单一因素引发。判断时，先别急着归咎于max_connections太小，更常见的原因是连接池配置过大且回收不及时，大量Sleep连接堆积；其次是应用代码未正确释放连接，造成连接泄漏；再者是慢SQL或突发流量把单条连接执行时间拉长，形成“堆积效应”。高峰期瞬间触顶，往往是这三类问题叠加的结果，只处理其中一项，故障很快会再次出现。

3. 连接数满对业务有何影响？

连接数满后，新连接被拒绝，业务直接报错。若故障持续，应用侧请求会不断重试或排队，进一步增加负载，甚至拖垮应用实例。更隐蔽的影响是，在连接数饱和状态下，正常查询的响应时间也会被拉长，数据库整体性能下降。很多团队在此时手动kill会话，却因分不清空闲连接和活跃会话，误杀了正常业务请求。

二、快速定位当前连接会话

当业务侧开始出现 Too many connections 报错，意味着 RDS 实例的客户端连接数已经触顶。此时第一件事不是急着调参数，而是先回答三个问题：当前到底有多少连接？是谁占用的？哪些连接是可以安全清理的？ 以下操作均可在 RDS 控制台的「数据库管理」或通过 DMS（数据管理服务）执行，不需要重启实例。

1. 查看当前连接总数与使用率

先跑一条命令确认水位：

SHOW STATUS LIKE 'Threads_connected';

Threads_connected 表示当前实际打开的客户端连接数。用这个数字除以实例的 max_connections 参数值，就能算出连接数使用率。比如返回 800，而 max_connections 是 1000，使用率已经到 80%——按行业经验，持续超过 70% 就该预警了。

再看另一个关键指标：

SHOW STATUS LIKE 'Threads_running';

Threads_running 表示当前正在执行查询的线程数，这个值更能反映数据库的真实负载。如果 Threads_connected 很高但 Threads_running 很低（比如只有个位数），说明大量连接处于空闲态，问题出在连接管理而非 SQL 性能上。

2. 识别异常会话：谁是占用连接的“元凶”

用这条 SQL 拉出所有会话的明细：

SELECT id, user, host, db, command, time, state, info 
FROM information_schema.processlist 
ORDER BY time DESC;

重点关注两个字段：

• command：值为 Sleep 表示连接正处于空闲状态。大量 Sleep 连接堆积，通常指向应用层连接泄漏或连接池回收参数配置不当。
• time：表示会话已经处于当前状态多少秒。一个 Sleep 会话的 time 如果超过了 wait_timeout 阈值（云数据库 MySQL 版默认通常是 86400 秒，即 24 小时），说明这个连接早就该被回收了。

更高效的做法是按来源 IP 和状态做聚合统计：

SELECT host, command, COUNT(*) AS cnt 
FROM information_schema.processlist 
GROUP BY host, command 
ORDER BY cnt DESC;

这条 SQL 能直观地看到：是哪个应用服务器 IP 占用了最多连接？其中多少是 Sleep 空闲连接？多少是正在执行查询的活跃连接？比如生产环境出现「10.0.x.1 这个 IP 占了 300 个连接，其中 280 个都是 Sleep」，基本可以锁定是这个应用节点的连接池没有正确回收空闲连接。

3. 手动终止空闲连接的正确姿势

确认了要清理的会话 ID 后，执行：

KILL ;

但有两个原则必须遵守：

第一，只杀 Sleep 超过一定阈值的连接。 比如 /tmp/mysql.sock 直连的运维会话、time 超过 300 秒的 Sleep 会话。对于正在执行中的 Query 会话，如果执行时间超过 30 秒且 state 显示为 Sending data 或 Copying to tmp table，大概率是慢 SQL，杀掉前需要评估影响——最好先确认这条 SQL 的来源应用，而不是直接 kill。

第二，批量清理要写脚本控制节奏。 不要一次性 kill 掉几百个连接。生产环境建议分批操作，每批 50 个左右，间隔几秒观察实例负载变化。如果杀完一批后 Threads_connected 没有明显下降，说明应用在疯狂重连，这时候继续 kill 只会加剧问题。

手动 kill 只是止血手段。真正要解决的是为什么连接会被占满——这通常指向应用连接池配置、慢 SQL 堆积或实例规格过小等问题。后续的参数调整和连接池优化，会在第三节和第四节详细展开。

4. 常见问题 FAQ

Q1：为什么 SHOW STATUS LIKE 'Threads_connected' 返回的数字和 RDS 控制台监控显示的不一致？

RDS 控制台的「连接数」监控指标通常包含内部系统连接（如管控、备份、监控等），而 Threads_connected 只统计客户端连接，两者存在几十甚至上百的差值，属正常现象。排查时应以控制台监控为准判断是否接近上限，以 Threads_connected 为准分析业务连接行为。

Q2：KILL 掉 Sleep 连接后，为什么几秒后又满了？

这说明应用连接池在持续创建新连接。常见原因：连接池的 maximumPoolSize 设置过大（如 HikariCP 设成 200，但实例 max_connections 才 300），或者连接池的空闲回收时间远大于 RDS 的 wait_timeout，导致 RDS 主动断开后应用立即重连。需要从连接池参数层面治理，单纯 kill 解决不了。

Q3：在 DMS 里执行 SHOW PROCESSLIST 会影响到线上业务吗？

不会。SHOW PROCESSLIST / 查询 information_schema.processlist 是只读操作，不会加锁也不会阻塞业务。但 KILL 操作会中断目标会话，执行前务必确认会话来源和运行状态。

Q4：阿里云 RDS 有没有现成的会话管理工具？

有。RDS 控制台的「CloudDBA（数据库智能管家）」提供实时会话管理功能，可以直接在界面上查看会话列表、按用户/主机/IP 筛选、批量 kill 会话，比手敲 SQL 更安全。另外 DMS 的「实例会话」功能也支持可视化查看和终止会话，适合不熟悉命令行的运维同事。类似能力在华为云 RDS 的「DBA 智能运维」中同样提供，如果你所在环境是华为云，控制台路径略有差异但排查思路一致。

三、优化应用连接池配置

连接池是应用与数据库之间的“缓冲层”，它的参数设置直接决定了RDS实例的连接压力。现实中大量案例表明，连接数超限并非数据库本身容量不足，而是应用连接池的默认配置与实例规格不匹配。比如某制造企业MES系统上线初期，HikariCP采用默认的maximumPoolSize=10，但应用部署了20个节点，峰值时段瞬间产生200个连接，直接打满RDS的max_connections默认值（通常为200~500），导致Too many connections报错。这类问题在微服务架构和WEB3高并发场景中尤为常见——连接池的“每个实例”口径与RDS的“实例级”上限之间存在显著落差。

1. 连接池参数怎么设置？

连接池的核心参数包括maximumPoolSize（最大连接数）、minimumIdle（最小空闲连接数）、connectionTimeout（获取连接超时时间）和idleTimeout（空闲连接回收时间）。其中，maximumPoolSize是最关键但也最容易被误配的参数。

操作说明：

以Java生态最常用的HikariCP为例，其核心配置如下：

spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 3000
      idle-timeout: 600000
      max-lifetime: 1800000

如果使用Druid，则对应配置为：

spring:
  datasource:
    druid:
      max-active: 20
      initial-size: 5
      min-idle: 5
      max-wait: 3000
      min-evictable-idle-time-millis: 600000

效果说明：

minimum-idle设为5意味着即使业务低峰，连接池也保底保留5个连接，避免频繁创建连接的开销。connection-timeout设为3000ms表示应用在3秒内拿不到连接即报错，这比默认的30秒更能快速暴露问题——如果连接池打满，3秒内就会触发告警，而不是让请求无限排队拖垮应用线程。idle-timeout设为10分钟是经验值，既能及时回收空闲连接，又不会像1分钟那样频繁销毁重建连接，反而增加数据库压力。

需要特别强调的是，连接池参数没有“标准答案”，必须结合实际业务链路压测调整。比如同一个应用，在MySQL 8.0和RDS MySQL 5.7上的最优配置可能完全不同——前者支持caching_sha2_password插件，连接认证开销更低，连接池可以相对大一些；后者使用mysql_native_password，连接创建成本更高，更依赖minimum-idle的保底机制。

2. 如何合理设置最大连接数？

这一节解决的是连接池与RDS参数的口径对齐问题。原则很简单：应用连接池的总和必须小于RDS的max_connections，且预留30%左右的余量给运维直连、监控采集、备份连接和突发流量。

操作说明：

先确认RDS实例的max_connections当前值：

SHOW VARIABLES LIKE 'max_connections';

假设返回值为200，那么预留30%后，所有应用连接池的maximum-pool-size总和不应超过140。如果应用节点数为10，则每个节点的maximum-pool-size不宜超过14。这里有一个常见的反面案例：某金融客户的RDS为4核8GB规格，max_connections默认300，但线上12个应用节点各自的连接池都设了50，总计600，远超实例上限。更严重的是，这些连接大多是Sleep状态——应用没有正确关闭连接，连接池也没有设置空闲回收，最终DB在高峰期被无效会话耗尽资源，业务链路秒级不可用。

具体调整建议：

Step 1: 登录RDS控制台 → 参数设置 → 搜索“max_connections”，记录当前值
Step 2: 统计所有应用节点的连接池最大连接数之和，与实例上限比对
Step 3: 按“总和 ≤ 上限×70%”为目标，缩减各节点连接池大小
Step 4: 观察Threads_connected实际使用率，控制在60%~70%以内为健康

效果说明：

调整后，连接数使用率从原来的95%降到65%左右，Too many connections报错消失，CPU和内存压力也同步下降——因为每条连接都会占用线程资源和内存缓冲区。这在业务维度上的体现就是：高峰期接口响应时间不再出现锯齿状抖动，慢SQL数量从每小时几十条降到个位数。核心差异在于，连接池缩减后，应用层的并发请求被“挡”在数据库之外，通过排队机制将压力平滑化，而不是把突发流量直接打在数据库上。

3. 连接池与RDS参数如何配合？

连接池参数不是孤立的，它必须与RDS侧的wait_timeout、interactive_timeout、thread_cache_size协同工作。这三者的配合逻辑是：连接池负责控制连接的产生和回收，RDS参数负责兜底释放异常残留的会话。

操作说明：

先看RDS侧当前的三个参数：

SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'interactive_timeout';
SHOW VARIABLES LIKE 'thread_cache_size';

配合策略如下表：

具体到操作层面，wait_timeout的调整有一个“先降后观察”的节奏：

Step 1: 将wait_timeout从默认的28800秒（8小时）降至3600秒
Step 2: 观察Threads_connected的峰值变化，如果降幅不明显，继续降至1800秒
Step 3: 每一步调整间隔不低于48小时，确保覆盖业务周期（包含周末峰值）
Step 4: 如果应用侧存在长事务（如报表查询），wait_timeout不宜低于900秒，否则长事务可能被异常断开

效果说明：

这个组合调整的效果是双层的。第一层，连接池的idle-timeout负责主动清理空闲连接，避免池内堆积“僵尸连接”；第二层，RDS的wait_timeout兜底处理那些连接池没有回收的残留会话——比如应用代码中Connection对象未显式close()，或线程池任务异常中断导致连接泄漏。当两层机制同时生效时，Sleep会话数量会显著下降。

一个可验证的数据点是：调整前某业务库的Threads_connected长期维持在180~200（上限200），其中Sleep会话占比约70%；调整后，Threads_connected稳定在40~60，Sleep占比降至20%以下。这意味着同规格的RDS实例有了更大的承载余量，相当于在不上浮规格的情况下增加了可用连接容量。

FAQ

• Q1：连接池的maximumPoolSize是不是越大越好？
  不是。每个连接都占用RDS的内存和线程资源，过大的连接池会导致CPU忙于上下文切换，反而降低单条SQL的执行效率。建议先压测确认单节点的合理并发数，再乘以节点数，确保总和小于实例max_connections的70%。

• Q2：调整max_connections会不会导致实例重启？
  在阿里云RDS中，max_connections是动态参数，控制台修改后不需要重启实例就会生效。但需要关注的是，调高它并不会增加底层资源，只是放开了连接上限——如果CPU和内存已经饱和，调高反而可能加速雪崩。

• Q3：为什么我设置了连接池maximumPoolSize=10，但数据库里能看到15个连接？
  因为连接池参数控制的是“池内保有的连接数”，但应用本身可能还有未归还的额外连接（如连接泄漏），或者RDS侧存在来自其他应用的连接。排查方式是执行SHOW PROCESSLIST，查看Host列的来源IP，确认哪些连接来自当前应用节点，再对比连接池的实际活跃连接数。

四、调整RDS核心参数

连接数超限后，参数调优是很多人第一个想到的手段，但也是最容易被误用的环节。参数调整的原则是：先确认瓶颈在“连接配额”还是“连接堆积”，再决定动哪个参数。以下三个核心参数的调整方法，按实际运维场景拆开讲。

1. max_connections参数如何调？

max_connections是实例允许的最大客户端连接数，属于硬限制，超过即拒绝新连接。但“调大”不是无脑操作，它受实例规格（内存、CPU）约束，调得过高反而加速资源耗尽。

先做诊断，再动参数。连接数超限时，先执行以下SQL确认当前水位：

-- 查看当前连接数与上限比值
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL VARIABLES LIKE 'max_connections';

如果Threads_connected / max_connections持续高于85%，才考虑调参。调大路径：RDS控制台 → 参数设置 → 搜索max_connections → 修改值 → 提交。每次仅增加10%~20%，例如当前是2000，先调到2400，观察30分钟CPU、内存和活跃会话数（Threads_running）变化，确认无异常后再决定是否继续调。

需要注意：当max_connections已经是该规格默认推荐值的上限附近时，继续调大通常不会生效或加剧资源争用——此时应该评估升级实例规格，而不是硬调参数。改参数解决的是“配额不够”的问题，解决不了“连接怎么用”的问题。

2. wait_timeout和interactive_timeout怎么设？

这两个参数控制连接空闲超时时间，单位秒。两者区别在于：wait_timeout针对非交互连接（应用通过连接池建立的连接），interactive_timeout针对交互式连接（如mysql命令行直连会话）。超时后由服务端主动断开，释放连接资源。RDS实例默认值通常是28800秒（8小时），这对大部分互联网业务来说太长了。

建议优先调整wait_timeout：如果information_schema.processlist中大量会话处于Sleep状态且time值很大，说明连接占了坑不干活。将wait_timeout从28800调整为1800（30分钟）或3600（60分钟），能促使服务端更快回收空闲连接。这两个参数的修改同样在“参数设置”页面完成，提交后无需重启实例（部分版本自动生效）。

但有一个反直觉的坑要提醒：wait_timeout设置过短，会导致正常的长连接被频繁断开。应用连接池如果配置了testOnBorrow之类的校验机制，断连后会重新建立连接，频繁建连在高并发场景下反而放大开销。建议从1800秒起步，观察一周内Threads_connected的峰值变化和慢查询日志，再决定是否继续调低。

此外，interactive_timeout建议保持默认或略调低至7200秒。DBA手动连上去排障时，很少会把一个交互会话挂几小时不放。

3. 其他相关参数有哪些？

• thread_cache_size：控制线程缓存数量，避免频繁创建和销毁连接线程。默认值通常够用，如果监控中Threads_created指标持续走高，可以适当调大到64或128。但这个参数属于可调可不调，属于“锦上添花”，不是解决连接数超限的关键。

• innodb_lock_wait_timeout：行锁等待超时时间，默认50秒。如果业务中存在大量并发更新同一行或慢事务持锁场景，连接会长时间卡在锁等待上，挤占连接配额。可以调低到10~20秒，让锁等待快速失败，释放连接。但要注意：如果业务代码没有重试机制，调低这个值会增加报错频率。调之前必须和业务方确认对锁冲突的容忍度。

• 连接池参数联动：这是最容易被忽略的一层。RDS的max_connections是实例层面的总闸，而应用连接池（HikariCP、Druid）的maximumPoolSize是单节点配置。多个应用节点部署时，池大小累加会轻松顶破RDS配额。连接池的maximumPoolSize务必小于RDS的max_connections，建议预留20%-30%配额给DBA直连、监控采集、备份链路使用。同时把连接池的connectionTimeout设置在3~5秒，避免应用侧无限制等待获取连接，与RDS的wait_timeout形成“谁先断”的合理协作。

参数层的调整只能缓解“连接被占满”的表象，核心还是要配合会话定位和慢SQL治理。如果调完参数后连接数仍然周期性触顶，说明问题出在应用侧连接管理上——这时回头查连接池配置和SQL执行效率，比继续调参数更有价值。

五、建立监控与预防机制

连接数超限有一个容易误导人的特点：它不是瞬间被击穿的。正常情况下，Threads_connected 曲线会在故障前一两个小时就开始持续爬升，真正报 Too many connections 时，实例已经接近容量极限，留给排查的时间窗口很短。更麻烦的是，连接打满后，执行 SHOW PROCESSLIST 本身也可能因为拿不到连接而失败。所以，监控和预防的重点不是「发生后快速处理」，而是在曲线爬升阶段就发现异常。

1. 如何设置连接数告警？

告警指标建议用「连接数使用率」而不是绝对连接数。不同实例规格的 max_connections 默认值差异很大——8C16G 和 16C32G 的上限可能相差一倍——只看 Threads_connected 的绝对值，很难判断当前水位是否危险。使用率的计算方式很直接：

Threads_connected / max_connections × 100%

假设实例规格默认 max_connections 为 2000，当前 Threads_connected 为 1400，使用率就是 70%。这个值比绝对数更直观，也能在不同规格之间做横向对比。

阈值建议分三档设置：

• 70% 预警：推送到运维群，确认是否有异常爬升，暂不干预。
• 85% 告警：进入处理流程，开始查看 processlist 和慢 SQL 情况。
• 95% 紧急：立即介入，优先处理空闲会话或临时限流。

采集频率建议 5 分钟一次，连续 3 次触发再发送通知，避免毛刺造成告警轰炸。

另外建议再挂一个指标：Threads_running。这个值反映「当前正在执行的会话数」，和 CPU 负载的相关性比 Threads_connected 更高。如果连接数使用率 80% 但 Threads_running 很低，说明大部分连接处于 Sleep 状态，问题大概率在连接池回收机制；反之，如果 Threads_running 长期超过 CPU 核数，说明有慢 SQL 或锁等待在堆积，走的是另一条排查路径。两个指标分开设置告警，故障时才能快速分流。

2. 定期巡检哪些指标？

巡检的重点不是「看有没有告警」，而是记录趋势。建议每周固定两次巡检，分别在业务低峰和高峰时段各做一次，重点看以下四项：

连接数使用率。关注周同比和日环比。如果每周同一时段的使用率持续上涨——比如从 55% 涨到 65% 再涨到 72%——说明连接数在缓慢泄漏，根因可能是应用没正确调用 connection.close()，也可能是连接池的空闲回收参数配置有误，需要尽快定位。

活跃会话数 Threads_running。这是真实并发，不是连接数。以 8 核实例为例，如果 Threads_running 长期超过 8，说明 CPU 已经排队，SQL 执行效率有问题。高并发场景下，一条执行 500ms 的 SQL 就能让这个指标显著跳升。

Sleep 会话占比。可以通过 processlist 直接统计：

SELECT command, COUNT(*) AS cnt
FROM information_schema.processlist
GROUP BY command
ORDER BY cnt DESC;

正常情况下，Sleep 占比在 30% 以内属于健康。如果超过 60%，说明大量连接被占着但不干活。这种情况优先检查应用连接池的 minIdle、maxIdleTime 等空闲回收参数，而不是急调 RDS 的 wait_timeout。

慢 SQL 趋势。包括单条 SQL 的平均耗时、最大耗时和每分钟慢 SQL 数量。慢 SQL 是连接堆积的放大器：一条执行 5 秒的 SQL，在并发 50 的情况下，最多会同时占用 50 个连接等待执行结果。

巡检时可以周期性执行这条 SQL，按来源和状态聚合，快速定位异常来源：

SELECT host, command, COUNT(*) AS cnt, MAX(time) AS max_seconds
FROM information_schema.processlist
GROUP BY host, command
ORDER BY cnt DESC;

如果某个 host 的 Sleep 连接数特别多且 max_seconds 很高，基本可以确定是某一个应用节点没有正确归还连接。

3. 如何规划容量应对高峰？

规划之前先明确一个事实：连接数上限不是独立的性能指标，它受内存和 CPU 约束。每个 RDS 规格都有对应的默认 max_connections 上限，强行调高只会让更多请求同时挤进实例，加剧共享资源争抢，CPU 和内存先被打满，最终数据库整体响应变慢，反而进一步加重连接堆积。

容量规划建议分两步走：

第一步，找到峰值规律。打开云监控的历史曲线，观察连接数使用率和 CPU 使用率的周期变化。制造业 ERP 系统通常在月末结账时段出现高峰，金融机构多在日终清算前后，电商则在活动大促期间。规律找得越清楚，越能提前准备资源。

第二步，核对连接池参数与 RDS 参数的配合度。应用侧连接池的 maximumPoolSize 总和要低于 RDS 的 max_connections，预留 20%～30% 给运维直连、监控采集和备份链路。举个例子：RDS 的 max_connections 是 2000，三个应用节点各部署一个连接池，每个连接池上限设置在 400～450 之间比较合理，而不是每个都设到 700。

wait_timeout 的调整要基于实际观测数据。很多团队为减少 Sleep 连接，把 wait_timeout 从默认值直接改成 60 秒，结果是正常的长连接被频繁断开，应用线程反复重建连接，数据库端创建连接的开销反而更大。合理的做法是先看 processlist 中 Sleep 连接的 time 分布：如果大多数空闲连接集中在 5～10 分钟，wait_timeout 设置 600 秒就够用；如果业务本身需要维持长连接，应该优先调整连接池的空闲回收参数，让应用主动断开，而不是用 RDS 参数强行「兜底」。

最后需要明确：升级规格是容量规划里优先级最低的选项。它只能解决容量不足，解决不了连接管理混乱。慢 SQL 不治理、连接池参数不收敛，升完规格后连接数依然会在下一次高峰打满，只是故障时间延后了。合理的处理顺序是：治理慢 SQL → 调整连接池参数 → 微调 RDS 参数 → 最后才评估升配。

六、总结与最佳实践建议

连接数超限（Too many connections）本质是实例级max_connections硬限制被击穿，但很多团队把它误解为“单纯连接池调大就能解决”。实际上，阿里云RDS连接数超限优化需要同时处理会话层、应用层和参数层：先用processlist定位异常会话，再调整连接池和wait_timeout，最后才考虑是否升级规格。下面给出一套从故障到预防的闭环动作，每一步都基于MySQL公开机制，可在控制台和SQL命令中直接验证。

1. 遇到连接超限时应按什么步骤处理？

第一步：止血，先看总连接数。
在DMS或客户端执行：

SHOW STATUS LIKE 'Threads_connected';

如果该值已经达到或接近max_connections，立即通过information_schema.processlist找出空闲会话：

SELECT id, user, host, db, command, time, state, info
FROM information_schema.processlist
WHERE command = 'Sleep' AND time > 100;

确认time远大于业务正常空闲范围后，执行KILL id;批量清理。效果： 对“连接泄漏”或“空闲连接堆积”型故障，几分钟内就能释放几十到上百个连接，业务报错迅速恢复。注意只kill确认空闲或明确异常的会话，不要kill正在运行的大事务。

第二步：定位根因，判断是慢SQL还是连接池失控。
查看活跃会话数：

SHOW STATUS LIKE 'Threads_running';

如果活跃会话数持续超过10，且processlist中Command=Query的time普遍大于1秒，基本可以确认是慢SQL拖住了连接。此时把info字段的SQL抓出来，结合RDS慢查询日志或SQL审计，定位具体语句。

第三步：治理，按根因做对应调整。
- 慢SQL：先加索引或改写查询，不要盲目清会话；
- 连接池配置过大：将应用连接池的maximumPoolSize调小到RDS上限的70%~80%；
- 连接泄漏：检查代码是否有finally中关闭连接，或使用try-with-resources。

第四步：复盘，将参数调整记录沉淀到参数模板。
记录本次max_connections、wait_timeout等参数调整前后的值，以及监控指标截图，避免下次故障时重新踩坑。

2. 日常如何避免连接数满？

日常治理的核心是让连接数使用率（Threads_connected / max_connections）始终处于可控水位，而不是等问题爆发后手动干预。

动作一：连接池参数与RDS参数联动配置。
应用侧连接池（如Druid、HikariCP）的maximumPoolSize应小于RDS的max_connections，预留20%~30%给运维直连、监控采集和备份链路。例如RDS max_connections为500，应用侧最大池大小建议控制在350~400。同时设置空闲回收：Druid配置minEvictableIdleTimeMillis=60000，HikariCP配置idleTimeout=60000。效果： 避免连接池内堆积大量空闲连接，RDS侧Sleep会话数会显著下降。

动作二：合理设置wait_timeout，但不要“一刀切”设得太小。
如果默认值是28800秒（8小时），对多数互联网业务偏长。建议先观察业务连接空闲分布，再逐步下调到1800秒（30分钟）或3600秒（1小时）。注意不要小于应用心跳间隔，否则正常连接会被频繁断开，反而增加建连开销。效果： 服务端主动回收空闲连接，连接数使用率通常会下降10%~20%。

动作三：建立“连接数使用率”告警，比业务报障先一步。
在云监控中设置阈值： - 70%预警：检查连接池是否偏大；
- 85%告警：开始定位会话来源；
- 95%紧急：立即执行会话清理。

同时关注Threads_running和慢SQL数量。效果： 将故障发现从“用户报障后”提前到“指标异常时”，给运维留出处置缓冲期。

3. 是否应该升级实例规格？

升级规格是“最后选项”，不是“第一选项”。一个简单的判断标准：如果连接数使用率长期高于90%，但CPU使用率低于50%、慢SQL很少，说明实例确实缺少连接容量，升级规格有效；反之，如果CPU已打满、慢SQL成堆，升级规格只会让更多请求涌进来，加速雪崩。

实际案例中，不少团队把连接数超限归结为“实例太小”，直接从4核8G升到16核64G，发现max_connections从800涨到2000，但应用连接池配置的是5000，几天后再次超限。这不是容量不够，而是池化配置和连接管理问题。

升级前先确认三个事实：

1. 应用连接池最大连接数是否已经超过实例上限？如果是，先改池子；
2. 是否有大量Sleep会话堆积？如果是，先修连接泄漏；
3. 是否有慢SQL占着连接不放？如果是，先优化SQL。

如果以上三点都排除，再考虑升级。升级时留意两个数值：CPU/内存水位，以及升级后max_connections的增量。阿里云控制台的“参数设置”页面会展示不同规格对应的连接数上限，建议把目标规格的默认值记录到变更文档，避免事后遗忘。

4. 常见问题FAQ

Q1：把max_connections调高并重启了，为什么还提示Too many connections？
A：max_connections是硬上限，调高后可用连接数确实增加，但如果应用连接池本身配置了超过该值的连接数，或存在连接泄漏，新上限很快会被再次填满。调参前先执行SHOW STATUS LIKE 'Threads_connected'，确认当前实际连接数。如果实际连接数没有明显下降，优先排查应用侧。

Q2：wait_timeout设置多少合适？
A：建议从业务侧的空闲连接分布出发。先查看SHOW STATUS LIKE 'Aborted_connects'和processlist中Sleep会话的time分布。大多数连接空闲超过30分钟，可将wait_timeout设为1800秒；如果有长连接保活机制，需要大于心跳间隔，并确保应用能处理服务端断开的异常。

Q3：手动kill会话有风险吗？
A：有。kill一个正在执行大事务或批量写入的会话，会导致事务回滚，可能出现锁定或写入失败。务必先通过processlist确认：Command=Sleep且time远超正常阈值；或Command=Query且执行时间远大于SQL平均耗时。生产环境操作前建议先在低峰期验证。

以上内容基于MySQL通用参数机制和阿里云RDS控制台的公开配置能力。不同地域、不同RDS版本的控制台路径和默认值可能略有差异，涉及具体参数调整时，以阿里云官方帮助文档为准。