如何在MySQL5.7中防范长事务导致的连接池耗尽-mysql教程-PHP中文网

长事务直接导致连接池打满，因InnoDB中每个活跃事务绑定一个连接且未提交前无法归还；30个长事务即可占满30连接池，触发超时错误。

如何在mysql5.7中防范长事务导致的连接池耗尽

长事务为什么直接导致连接池打满

MySQL 5.7 的 InnoDB 引擎中，每个活跃事务必须绑定一个数据库连接。事务不结束（没 COMMIT 或 ROLLBACK），连接就无法归还给池子。假设连接池大小是 30，30 个长事务同时卡住，新请求立刻触发 Connection is not available, request timed out after 30000ms —— 这不是连接不够，是连接被“钉死”了。

常见诱因包括：存储过程中漏写 COMMIT、autocommit = 0 后异常分支未回滚、SQL 执行慢（如没走索引的 SELECT * FROM orders WHERE user_id = ?）导致事务持续占用连接。

怎么快速定位正在拖垮池子的长事务

别猜，直接查 information_schema.innodb_trx 表：

SELECT trx_id, trx_started, TIME_TO_SEC(timediff(NOW(), trx_started)) AS duration_sec,
       trx_state, trx_query 
FROM information_schema.innodb_trx 
WHERE TIME_TO_SEC(timediff(NOW(), trx_started)) > 30;

重点关注 duration_sec 超过 30 秒、trx_state = 'RUNNING' 且 trx_query 非空的记录。如果 trx_query 是 CALL proc_xxx()，基本可锁定问题在存储过程内；如果是普通 DML，则检查是否遗漏提交或被锁阻塞。

配合 SHOW FULL PROCESSLIST 看 Command = 'Query' 且 Time > 30 的线程，确认是否正执行慢 SQL
用 SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 60 找滞留连接，它们往往是前一个事务没结束的“后遗症”
别忽略 TRX_WAITING_TRX_ID 字段——有值说明已陷入锁等待，得顺藤摸瓜查阻塞源

Java 应用里调用存储过程时最容易踩的坑

绝大多数连接泄漏发生在 Java 层调用 MySQL 存储过程后资源未释放，不是连接池配置小，而是连接根本没“松手”。

典型错误写法：CallableStatement 执行完没关、只关了 ResultSet 漏掉 CallableStatement、手动 close() 顺序错或放在 if 分支里漏执行。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

正确姿势只有两个选择：

强制用 try-with-resources，确保 CallableStatement 和所有 ResultSet 自动关闭：

try (CallableStatement cs = conn.prepareCall("{CALL proc_update_status(?)}")) {
    cs.setInt(1, orderId);
    cs.execute();
    // 不用手动 close，作用域结束自动释放
}

若必须手动管理，必须按 ResultSet → CallableStatement → Connection 顺序在 finally 块中关闭（Connection.close() 在连接池中实际是归还操作）
启用 HikariCP 的 leakDetectionThreshold=60000（60 秒），一旦超时未归还，日志会打出完整堆栈，精准定位哪行代码漏关