MySQL：长事务不提交把连接池活活占满，应用报“Connection is not available”但数据库看连接数正常，怎么排查？

目录

一、引言：一个"两边对不上"的经典故障

线上告警响起，应用日志里成片出现 Connection is not available, request timed out after 30000ms，接口大面积超时。值班工程师第一反应是"数据库连接被打满了"，于是登录 MySQL 执行 show status like 'Threads_connected'，结果只有一百多，而 max_connections 是 1000。数据库看起来"很闲"，应用却"拿不到连接"。这个矛盾本身，就是最有价值的线索。

这类故障在微服务架构中并不罕见。它的迷惑性在于："连接数"这个词在应用侧和数据库侧指向的不是同一个集合。应用侧统计的是"池内对象状态"，数据库侧统计的是"服务端会话状态"，两者之间隔着 TCP 连接、认证、会话初始化、事务状态、归还逻辑等多个环节。任何一个环节的语义偏差，都会让两边数字对不上。

本文的主线只有一条：沿着一条物理连接从"借出"到"归还"的完整生命周期，找出它在哪一段被卡住、为什么卡住、以及如何用可观测手段把它定位出来。所有章节都围绕这条主线展开，不铺陈无关的 MySQL 调优知识。笔者认为，长事务占满连接池之所以难排查，本质是"资源泄漏"与"资源耗尽"被混为一谈——连接并没有消失，它只是被一个未结束的事务"合法地"扣留着。

排查心法：当应用侧报"资源不足"而服务端报"资源充足"时，先不要怀疑监控，而要怀疑"资源"这个词在两边的定义是否一致。定义对齐，问题往往就浮出水面。

二、背景与问题定义：连接池计数与数据库会话为何会错位

2.1 两个"连接数"的准确定义

要讨论错位，先要给出定义。应用侧连接池（以 HikariCP 为例）对外暴露的核心指标是 HikariPool-1 - Active: N, Idle: M, Total: N+M, Waiting: K。其中 Active 表示已被业务线程借出、尚未归还的连接数；Idle 表示空闲可借的连接数；Waiting 表示正在等待借连接的线程数。数据库侧则通过 Threads_connected（当前打开的连接数）与 Threads_running（正在执行而非睡眠的线程数）刻画服务端负载。

关键差异在于：Active 连接在数据库侧通常表现为 Sleep 状态。一个业务线程借到连接、执行完 BEGIN 与若干 DML 之后，如果迟迟不 COMMIT，这条连接在服务端既不是"断开"，也不是"正在跑 SQL"，而是处于"会话空闲但事务未结束"的状态。于是 Threads_running 很低，Threads_connected 也只是等于池大小，看起来一切正常。但应用侧 Active 已经等于 maximumPoolSize，新请求只能排队，超时后抛出"Connection is not available"。

2.2 为什么"数据库连接数正常"是一个伪信号

很多团队把 Threads_connected 当作连接健康度的唯一指标，这是一个结构性误判。原因有三：其一，连接池的 maximumPoolSize 通常远小于 max_connections，池满时数据库侧根本不会告警；其二，长事务占用的连接在服务端处于 Sleep，不消耗 CPU，监控曲线平滑；其三，真正反映"事务悬挂"的指标是 information_schema.innodb_trx 中的 trx_started 与 trx_mysql_thread_id，而这两个字段很少被纳入日常看板。

本文评述：把 Threads_connected 当作连接池健康指标，等价于用"医院里有多少张病床被占用"来判断"有多少病人正在等待手术"。病床数没满，不代表手术室没被一台超长手术占住。连接池的"手术室"是 Active 连接，而它的状态在数据库侧恰恰是最不显眼的 Sleep。

三、原理剖析：连接生命周期、事务边界与池化语义

3.1 一条连接的完整生命周期

把连接当作一个对象，它的生命周期可以划分为六个阶段：创建（create）→ 借出（borrow）→ 使用（use）→ 归还（return）→ 空闲（idle）→ 销毁（evict）。长事务故障的根因，几乎总是发生在"使用"阶段——业务代码在借出连接后开启了事务，却因为异常路径、嵌套调用、异步回调或人为疏忽，没有走到 COMMIT 或 ROLLBACK，导致连接无法进入"归还"阶段。

需要强调的是，连接池的"归还"并不等于事务的"提交"。以 HikariCP 为例，Connection.close() 只是把连接对象放回池中，它默认会执行 rollback（若 autoCommit=false 且事务未结束），但这依赖驱动与池的配合。如果业务代码根本没有调用 close()，连接就永远停在"借出"状态，池的 Active 计数只增不减。

// 典型的长事务悬挂写法（反面示例）
Connection conn = dataSource.getConnection();   // 借出，Active +1
conn.setAutoCommit(false);
try {
    PreparedStatement ps = conn.prepareStatement("update account set balance = balance - ? where id = ?");
    ps.setBigDecimal(1, amount);
    ps.setLong(2, fromId);
    ps.executeUpdate();
    // 此处发生异常，或业务逻辑提前 return，未走到 commit
    // 且 finally 中只关闭了 PreparedStatement，未关闭 Connection
} catch (Exception e) {
    log.error("transfer failed", e);
    // 未 rollback，未 close
}
// 连接永远停留在 Active 状态，事务在服务端悬挂

这段代码的问题不在于"忘了 close"这么简单，而在于事务边界与连接边界没有对齐。事务的开始与结束应当由同一层代码负责，连接的借出与归还也应当由同一层代码负责。一旦二者被拆分到不同的抽象层（例如事务在 Service 层开启，连接在 DAO 层借出），异常路径就极易漏掉某一端的收尾。

3.2 事务悬挂在 InnoDB 内部意味着什么

从 InnoDB 的视角看，一个未提交的事务会持有一系列资源：行锁（record lock）、间隙锁（gap lock）、undo log 中的旧版本、以及一个活跃的 read view。这些资源不会因为连接处于 Sleep 而释放。随着时间推移，undo log 无法 purge，历史版本链不断变长，其他事务的可见性判断成本上升；若该事务持有行锁，相关行的更新会被阻塞，进而引发连锁的锁等待。

本文评述：长事务的危害是双重的。第一重是连接层面的资源占用，它直接导致连接池耗尽，这是应用报错的直接原因；第二重是存储层面的资源滞留，它表现为 undo 膨胀、锁等待、主从延迟，往往在连接池告警之后才逐渐显现。排查时若只盯着第一重，容易在"连接已释放"后误判故障已解除，而第二重的余波可能持续数小时。

可以用一条查询快速识别悬挂事务的年龄与来源：

SELECT trx_id,
       trx_state,
       trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS trx_age_sec,
       trx_mysql_thread_id,
       trx_rows_locked,
       trx_rows_modified,
       LEFT(trx_query, 120) AS current_query
FROM information_schema.innodb_trx
ORDER BY trx_started ASC
LIMIT 20;

其中 trx_age_sec 是判断"长"事务的核心依据。业界常见的经验阈值是 60 秒（OLTP 场景），但这不是绝对标准——批处理任务可能合法地运行数分钟。关键在于区分"预期内的长"与"预期外的悬挂"，前者应有明确的业务标签与白名单，后者才是故障源。

3.3 连接池的等待队列与超时语义

当 Active 达到 maximumPoolSize，新请求进入等待队列。HikariCP 的 connectionTimeout（默认 30 秒）决定等待上限，超时即抛出 SQLTransientConnectionException，消息即"Connection is not available"。这里有一个容易被忽略的细节：等待线程本身也占用资源，在 Tomcat 等容器中，等待连接的请求线程会堆积，最终可能把 Web 容器的线程池也拖垮，形成"连接池 → 线程池"的级联故障。

因此，connectionTimeout 不应设置得过大。设置过大，故障时线程堆积更严重；设置过小，则可能在数据库短暂抖动时误杀正常请求。笔者认为，该值应与上游服务的超时预算联动设计，而不是孤立地取默认值。

四、排查路径：从现象到根因的六步操作法

下面给出一条可复用的操作路径。每一步都对应一个可验证的判据，避免"猜"。整个流程的目标不是尽快重启恢复，而是在恢复之前留下足够的证据链，否则故障会周期性复发。

4.1 第一步：确认是"池内耗尽"而非"网络不可达"

先看应用侧指标。Active 是否等于 maximumPoolSize？Waiting 是否持续大于 0？如果两者同时成立，基本可以判定为池内耗尽。若 Active 不高但仍有超时，则要怀疑 DNS 解析、防火墙、连接创建失败等网络层问题，排查方向完全不同。

HikariCP 的 metricsTrackerFactory 可以把这些指标接入 Micrometer/Prometheus，建议至少暴露 hikaricp.connections.active、hikaricp.connections.pending、hikaricp.connections.timeout 三个指标，并配置"Active 持续等于上限超过 1 分钟"的告警。

4.2 第二步：在数据库侧定位悬挂事务

执行 3.2 节的 innodb_trx 查询，按 trx_started 升序排列。重点观察：是否有事务年龄远超业务预期？trx_rows_locked 是否异常大？trx_query 为空通常意味着事务已执行完最后一条语句但未提交，这正是"悬挂"的典型特征。

如果 innodb_trx 中看不到可疑事务，但连接池确实满了，那就要转向 performance_schema 或 processlist，检查是否存在"连接已借出但从未执行任何 SQL"的情况——这通常指向连接借出后卡在应用侧逻辑（如等待外部 RPC），而非数据库事务。

4.3 第三步：把事务 ID 映射回应用线程

这是整个排查中最关键、也最容易被跳过的一步。trx_mysql_thread_id 给出的是服务端线程 ID，它与应用线程没有直接映射。要建立映射，需要在应用侧采集"连接 → 线程"的对应关系。常见做法是：在连接池借出连接时，通过 SET @app_thread = '...' 或 JDBC 的 connection.setClientInfo() 写入业务标识，随后在 performance_schema.session_connect_attrs 中查询。

-- 查询会话属性，定位业务来源
SELECT t.PROCESSLIST_ID,
       t.PROCESSLIST_USER,
       t.PROCESSLIST_HOST,
       a.ATTR_NAME,
       a.ATTR_VALUE
FROM performance_schema.threads t
JOIN performance_schema.session_connect_attrs a
  ON t.THREAD_ID = a.PROCESSLIST_ID
WHERE a.ATTR_NAME IN ('_client_name', 'program_name', 'app_thread')
ORDER BY t.PROCESSLIST_ID;

本文评述：很多团队在故障复盘时只能说出"某个服务有长事务"，却无法定位到具体代码路径，根源就在于缺少这层映射。建议把"连接借出时写入业务标识"作为连接池的标准配置项，成本极低，收益极高。

4.4 第四步：抓取线程栈，确认阻塞点

拿到应用线程标识后，用 jstack（Java）或 py-spy（Python）抓取线程栈，观察该线程停在何处。若停在业务代码的某个 await 或 sleep，说明连接借出后业务逻辑阻塞；若停在 socketRead，说明在等待数据库响应（可能是慢 SQL 或锁等待）；若线程栈里根本找不到该线程，则可能是异步回调或线程池复用导致的"连接跨线程泄漏"。

这一步的价值在于把"事务悬挂"这个数据库现象，翻译成"某段代码没有正确收尾"这个应用问题。只有完成这个翻译，修复才有针对性。

4.5 第五步：验证修复，观察指标回归

修复后不要只看"报错消失"。要验证三个指标同时回归：应用侧 Active 回落到基线、Waiting 归零；数据库侧 innodb_trx 中不再有超龄事务；Threads_running 与 Threads_connected 的比值回到正常区间。若只有报错消失而 Active 仍缓慢爬升，说明存在未被覆盖的泄漏路径。

4.6 第六步：建立防复发机制

单次修复只能解决已知路径。要防止复发，需要三道防线：代码层（统一事务模板、强制 try-with-resources、静态扫描未关闭连接）、配置层（设置 innodb_lock_wait_timeout 与 max_execution_time，让异常事务自动失败而非无限悬挂）、监控层（长事务告警、连接池 Active 水位告警、等待队列长度告警）。

操作提示：MySQL 5.7.8 起支持 max_execution_time（单位毫秒，仅对 SELECT 生效），8.0 起可用 max_execution_time 与 innodb_lock_wait_timeout 组合兜底。注意前者不覆盖 DML，后者只覆盖锁等待，二者不能互相替代。

五、关键数据与案例：指标口径、阈值与真实故障复盘

5.1 指标口径对照表

下表汇总了排查中常用的指标及其口径。需要说明的是，表中"典型阈值"一列是基于公开文档与社区实践的经验区间，并非普适标准，读者应结合自身业务 RT 与 SLA 调整。

5.2 一次典型故障的复盘（模拟数据）

以下复盘基于笔者对同类公开案例的整合与模拟，数据为模拟数据，仅用于说明指标演化规律，不代表任何真实系统。

某订单服务，连接池 maximumPoolSize=20，数据库 max_connections=500。故障期间，应用侧 Active 在 8 分钟内从 3 爬升至 20 并保持，Waiting 从 0 升至 40 以上；数据库侧 Threads_connected 稳定在 20 左右，Threads_running 仅 1~2。表面看数据库"毫无压力"，但 innodb_trx 中有 20 个事务年龄在 300~480 秒之间，且 trx_query 全为空。

进一步用会话属性定位，20 个悬挂事务全部来自同一台应用实例的同一批线程，线程栈显示它们停在某个第三方 HTTP 客户端的 read 调用上。根因是：该段代码在事务内调用了外部接口，且外部接口在故障期间超时时间被配置为 120 秒，导致事务被长时间拉长。修复方式是把外部调用移出事务边界，并为该接口设置独立的短超时。

本文评述：这个案例的教训不是"不要在事务里调 RPC"这种老生常谈，而是事务边界的划定应当以"最慢的依赖"为参照。只要事务内包含一个不可控延迟的外部依赖，事务时长就失去了上界，连接池的容量设计也就失去了意义。

5.3 一个可复现的最小实验

若想在自己的环境中复现该现象，可以用两个会话完成：会话 A 执行 BEGIN; UPDATE t SET c=1 WHERE id=1; 后不提交；会话 B 执行 UPDATE t SET c=2 WHERE id=1; 会进入锁等待。此时观察 Threads_running 会短暂升高，但会话 A 始终是 Sleep。这个实验直观地说明：Sleep 会话可以是"最危险"的会话。

更多关于 InnoDB 锁与事务的可视化讲解，可参考 MySQL 官方文档的 InnoDB Locking 章节（dev.mysql.com/doc/refman/8.0/en/innodb-locking.html）以及 HikariCP 的配置说明（github.com/brettwooldridge/HikariCP）。

六、对比与局限：主流连接池与长事务治理方案横向评估

6.1 主流连接池的泄漏防护能力对比

本文评述：泄漏检测机制（如 leakDetectionThreshold）是"事后取证"工具，不是"事前预防"工具。它能在连接超时未归还时打印借出栈，帮助定位代码，但无法阻止连接被占用。真正的前置防线是事务模板化——用统一的 TransactionTemplate 或 AOP 切面管理事务边界，让业务代码无法"忘记"提交。

6.2 长事务治理方案的局限

常见的治理手段包括：设置 max_execution_time、配置 innodb_lock_wait_timeout、启用 wait_timeout、以及用 pt-kill 主动杀事务。这些手段各有边界：max_execution_time 不覆盖 DML；innodb_lock_wait_timeout 只作用于锁等待，对"事务内做 RPC"无效；wait_timeout 只杀空闲连接，而悬挂事务的连接在服务端恰恰是空闲的——但若业务仍在持有连接对象，杀会话只会让应用侧报"连接已关闭"，连接对象仍不归还，池仍然满。

笔者认为，治理长事务不能只靠数据库侧的"杀"，必须回到应用侧的"管"。数据库侧的强制手段适合作为兜底，用于防止单点故障扩散；应用侧的事务边界治理才是根治。二者是"消防"与"防火"的关系，不可倒置。

七、结论与展望：把连接当作一等资源来治理

回到最初的问题：为什么应用报"Connection is not available"而数据库看连接数正常？答案已经清晰——应用侧统计的是"借出未归还"，数据库侧统计的是"会话存在"，长事务让前者达到上限，却让后者保持平稳。排查的关键，是沿着连接生命周期找到"借出后未归还"的那一段，并用会话属性、线程栈、事务年龄三类证据交叉验证。

从更长的视角看，连接池容量是一个被严重低估的架构参数。它同时受限于数据库 max_connections、应用实例数、单请求持有时长、以及最慢依赖的延迟。任何一项变化，都会改变"安全容量"。笔者建议把连接池容量纳入容量规划评审，与 RT、QPS、实例数一起建模，而不是拍脑袋取一个"20 或 50"。

展望未来，随着云原生数据库代理（如 ProxySQL、MySQL Router）与可观测性标准的普及，"连接"正在从"应用内部对象"变成"可被独立观测与治理的资源"。OpenTelemetry 的数据库语义约定已经开始规范连接级 span 的属性，这为跨应用与数据库的连接追踪提供了基础。可以预期，未来的连接池将不再只是"对象缓存"，而是具备事务感知、依赖感知、容量自适应能力的资源调度器。

一句话总结：连接池满不等于数据库满；数据库闲不等于应用健康。把"连接"当作一等资源，用生命周期视角去观测它，这类"两边对不上"的故障就不再神秘。

主要参考文献