MySQL连接超时主因是应用端连接池配置不当，非数据库负载高；应调大maximumPoolSize、设合理minimumIdle、启用预编译缓存、禁用testOnBorrow、匹配wait_timeout与空闲回收周期、加socketTimeout、确保连接归还前事务结束和状态重置。
MySQL连接超时是连接池没撑住，不是数据库扛不住
高并发下报 com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure 或 java.sql.SQLNonTransientConnectionException: Could not create connection to database server，大概率不是 MySQL 本身负载高，而是应用端连接池在排队、超时、频繁重建连接。MySQL 默认能轻松支撑几百甚至上千活跃连接，但你的连接池如果配置过紧，maxActive（或 maximumPoolSize）设得太小，又没开连接重用，瞬时流量一来就卡在获取连接这步。
别只加 maxWait，重点调 maximumPoolSize 和 minIdle
很多团队第一反应是把 maxWait（如 HikariCP 的 connection-timeout）从 30s 拉到 60s，这只会让请求挂得更久，不解决根本问题。真正要动的是连接池容量和预热逻辑：
-
maximumPoolSize建议设为应用实例的 QPS × 平均 SQL 耗时（秒）× 1.5～2，例如 QPS=200、平均查询 80ms，则起步可设32（200 × 0.08 × 2 ≈ 32），再观察监控中active和idle曲线 -
minimumIdle别设为 0 —— 否则低峰期连接全释放，高峰期又要重新握手，TLS + TCP + 认证耗时叠加，极易触发超时；建议设为maximumPoolSize的 30%～50% - 确认驱动是否启用连接复用：MySQL Connector/J 8.0+ 默认开启
cachePrepStmts=true，但必须配prepStmtCacheSize=250+prepStmtCacheSqlLimit=2048才生效，否则每次prepareStatement都走全新协议流程
testOnBorrow 在高并发下是性能杀手
HikariCP 已弃用该参数，Druid 默认关，但老项目若还在用 DBCP 或自定义配置，务必检查：testOnBorrow=true 会让每次 getConnection() 都执行一次 SELECT 1，QPS 上千时等于凭空多出同等量级无效查询，延迟陡增。正确做法是：
- 用
connection-test-query=SELECT 1+testWhileIdle=true+timeBetweenEvictionRunsMillis=30000，只对空闲连接做保活检测 - 确保 MySQL 侧
wait_timeout≥ 连接池的空闲回收周期（如设 60s，则 MySQL 至少设wait_timeout=90），否则连接被服务端主动断开，池内连接变成“假活” - 连接字符串里加上
&socketTimeout=30000（单位毫秒），防止个别慢查询拖垮整个池
连接重用不只是「不关闭」，关键是复位状态
即使连接被归还到池中，若上一个事务未提交/回滚、临时表未清理、会话变量被污染（如 SET NAMES utf8mb4），下一个借用者可能拿到异常上下文。这不是连接池 bug，是使用姿势问题：
- 所有数据库操作必须包裹在
try-with-resources或显式finally { conn.close(); }中，确保归还前事务已结束 - 避免在连接上执行
SET @var := ...类会话变量赋值；如必须用，应在归还前RESET SESSION（MySQL 5.7.3+ 支持）或至少ROLLBACK清理事务状态 - HikariCP 默认开启
autoCommit=true，但如果业务代码手动设了conn.setAutoCommit(false)却忘了恢复，后续借用者会继承这个状态，导致隐式事务堆积
连接池不是黑盒，它只管借还，不管语义。状态残留比连接数不足更容易引发偶发超时，而且更难定位。
