尧图网页设计 
简介这份PDF文档面向使用MySQL数据库与c3p0连接池的Java后端开发者聚焦于连接空闲超过8小时后被MySQL自动断开、而连接池仍误判其有效并返回给客户端导致抛异常的典型故障。文档系统梳理了三种解决思路调整MySQL的wait_timeout与interactive_timeout参数、缩短连接池maxIdleTime使其小于数据库超时时间、以及通过preferredTestQuery与idleConnectionTestPeriod定期检测连接有效性并给出Spring配置文件中数据源bean的具体写法。资源包共1个PDF文件大小约45KB内容紧凑涵盖参数说明、配置示例与排错要点便于快速查阅与落地。目前已有7951人学习下载适合需要排查连接失效问题、优化连接池配置的开发者参考可帮助读者理解超时机制、掌握配置调整方法并减少生产环境中的连接异常。1. MySQL 连接空闲 8 小时后自动断开一个被低估的线上故障源头凌晨两点告警群炸了。一个跑了半年的定时任务突然开始报Communications link failure重启服务就好过一夜又挂。翻代码没改过翻数据库没重启过最后定位到一条冷知识MySQL 默认的wait_timeout是 28800 秒也就是 8 小时。连接池里的空闲连接一旦超过这个阈值服务端单方面掐断而客户端还以为这条连接活着下次借出去执行 SQL 就直接翻车。这不是玄学是 TCP 连接生命周期和 MySQL 会话管理之间一个非常具体的错位。这个问题的核心不是「MySQL 为什么会断开」而是「断开之后你的应用为什么不知道」。连接池、ORM 框架、驱动层各自有各自的保活策略配错一个参数就会在业务低峰期埋雷。下面按「先搞懂断开机制 → 再选保活方案 → 落到代码和参数 → 排掉常见坑」的顺序讲清楚适合后端开发、运维和正在搭连接池的工程师。2. 先搞清楚 MySQL 到底在什么条件下掐断连接2.1 wait_timeout 和 interactive_timeout 的真实作用范围MySQL 服务端有两个控制空闲连接的超时参数名字很像但作用对象不同。wait_timeout管的是非交互式连接也就是你的应用通过 JDBC、连接池建立的普通连接interactive_timeout管的是交互式连接比如你用 mysql 命令行客户端登进去敲 SQL 的那种会话。两个参数默认值都是 28800 秒。关键点在于连接池里的连接属于非交互式受wait_timeout约束。很多人改了interactive_timeout发现没用就是因为改错了对象。查看当前值的命令SHOW VARIABLES LIKE %timeout%;输出里会同时看到wait_timeout和interactive_timeout。如果你只想临时验证可以会话级设置SET SESSION wait_timeout 60;这条命令只影响当前会话断开重连就恢复全局值。要永久生效得改配置文件my.cnf的[mysqld]段然后重启或SET GLOBAL。但注意调大wait_timeout只是把雷埋得更深不是解决方案。因为网络中间设备防火墙、负载均衡也可能有自己的空闲超时你不可能无限调大。2.2 连接被掐断时客户端为什么毫无感知TCP 连接断开分两种一种是服务端发 FIN 包正常关闭客户端能收到另一种是服务端直接发 RST 或者中间设备静默丢包客户端完全不知道。MySQL 的wait_timeout到期后服务端会关闭会话但这个关闭动作不一定能及时通知到客户端尤其是连接经过多层网络设备时。更麻烦的是连接池的检测机制。连接池借出连接前通常会做一个validationQuery比如SELECT 1来验活但如果连接池配置的是「借出时不检测」或者「检测间隔太长」就会把一条已经死掉的连接交给业务代码。业务代码拿到连接执行 SQL第一次写操作可能成功因为 TCP 缓冲区还没报错第二次才抛异常。这就是为什么很多故障表现为「偶发」「重启就好」「过一段时间又出现」。理解这一点之后解决思路就清晰了要么让连接池主动淘汰空闲超时的连接要么让连接自己定期发心跳保持活跃要么在借出时强制验活。三种方案各有适用场景下面逐个拆。3. 连接池保活方案从 JDBC 参数到 HikariCP 配置3.1 JDBC URL 里的 autoReconnect 为什么不该用很多老教程会告诉你加autoReconnecttrue这个参数在 MySQL Connector/J 里确实存在但官方文档明确不推荐。原因是它只在执行 SQL 抛异常后才触发重连而且会丢失会话状态临时表、事务、用户变量全没了。更危险的是它可能让事务在不知情的情况下被重放或部分提交。正确的做法是在连接池层面解决而不是在驱动层。下面以目前主流的 HikariCP 为例给出一个能扛住 8 小时空闲的配置。3.2 HikariCP 的关键参数与完整配置示例HikariCP 有几个参数直接决定空闲连接会不会被服务端掐死参数建议值作用maxLifetime比wait_timeout小 30 秒以上连接最大存活时间到期主动关闭重建idleTimeout小于wait_timeout空闲连接回收时间keepaliveTime小于wait_timeout定期发送心跳包保活validationTimeout5000ms验活超时connectionTestQuerySELECT 1验活 SQLJDBC4 驱动可省略一个可抄的 Spring Boot 配置spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 idle-timeout: 600000 # 10分钟远小于8小时 max-lifetime: 1740000 # 29分钟比wait_timeout小 keepalive-time: 300000 # 5分钟发一次心跳 connection-timeout: 30000 validation-timeout: 5000 connection-test-query: SELECT 1max-lifetime设成 1740000 毫秒29 分钟是有讲究的MySQL 默认wait_timeout是 8 小时但很多云数据库会把它调到更短比如 30 分钟。设 29 分钟能保证连接在服务端掐断之前就被连接池主动回收重建。keepalive-time则是给空闲连接发心跳防止被中间网络设备判定为死连接。注意keepalive-time只在 HikariCP 4.0.0 及以上版本支持老版本没有这个参数只能靠max-lifetime和idle-timeout配合。3.3 用代码验证保活是否真的生效配完不能只看日志要实际验证。写一个简单的测试让连接空闲超过wait_timeout再执行查询// 模拟连接空闲后执行SQL SpringBootTest public class ConnectionKeepAliveTest { Autowired private DataSource dataSource; Test public void testIdleConnection() throws Exception { // 先拿一条连接执行一次 try (Connection conn dataSource.getConnection(); Statement stmt conn.createStatement()) { stmt.execute(SELECT 1); } // 等待超过wait_timeout测试环境可临时设为60秒 Thread.sleep(70000); // 再次获取连接执行 try (Connection conn dataSource.getConnection(); Statement stmt conn.createStatement()) { ResultSet rs stmt.executeQuery(SELECT 1); assertTrue(rs.next()); } } }这个测试的逻辑是第一次执行后连接归还池中等待超过服务端超时时间再借出连接。如果保活配置正确第二次执行不会抛Communications link failure。测试时可以把 MySQL 的wait_timeout临时设为 60 秒来加速验证但记得测完改回去。4. 不用连接池的场景手动保活与重试策略4.1 定时任务里的连接管理有些场景没有连接池比如 Python 脚本、定时任务、数据同步工具。这时候需要手动管理连接生命周期。核心原则是不要长期持有一条连接用完就关下次重连。如果业务要求保持长连接那就加心跳。Python 的pymysql示例import pymysql import time def get_connection(): return pymysql.connect( hostlocalhost, userroot, passwordpassword, databasetest, connect_timeout10, read_timeout30, write_timeout30 ) def keep_alive_loop(): conn get_connection() while True: try: # 每5分钟发一次心跳 with conn.cursor() as cursor: cursor.execute(SELECT 1) cursor.fetchall() time.sleep(300) except pymysql.err.OperationalError as e: # 连接断开重连 print(fConnection lost: {e}, reconnecting...) conn get_connection()read_timeout和write_timeout是关键参数它们控制 socket 层面的超时避免连接已经死了但程序还在傻等。心跳间隔设 300 秒远小于 MySQL 的 8 小时也小于大多数防火墙的空闲超时。4.2 重试逻辑怎么写才不会雪崩连接断开后重试是必须的但重试策略不对会引发雪崩。三个原则限制重试次数、加退避间隔、区分可重试异常。public T T executeWithRetry(SupplierT action, int maxRetries) { int attempt 0; while (true) { try { return action.get(); } catch (CommunicationsException | SQLTransientConnectionException e) { attempt; if (attempt maxRetries) { throw e; } // 指数退避最多等2秒 long backoff Math.min(1000L * (1L attempt), 2000L); try { Thread.sleep(backoff); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); throw new RuntimeException(ie); } } } }这里只捕获CommunicationsException和SQLTransientConnectionException这类连接层异常不捕获业务 SQL 异常。因为业务异常重试可能导致重复插入。退避时间用指数增长但设上限避免大量请求同时重试把数据库打挂。5. 避坑与排查那些让你白忙半天的细节5.1 改了 wait_timeout 但连接还是断现象把 MySQL 的wait_timeout调到 24 小时应用连接还是过一段时间就断。原因中间有防火墙或负载均衡它们有自己的空闲超时通常比 MySQL 短。TCP 连接在中间设备上被静默丢弃两端都不知道。解决不要依赖调大wait_timeout而是在连接池配keepaliveTime或maxLifetime让连接主动重建。同时检查网络设备的空闲超时配置。5.2 连接池验活 SQL 配了但没生效现象配了connectionTestQuery: SELECT 1但故障依旧。原因HikariCP 在 JDBC4 驱动下默认用Connection.isValid()而不是执行 SQLconnectionTestQuery可能被忽略。另外如果validationTimeout设得太短验活本身超时也会被跳过。解决确认驱动版本必要时强制指定connectionTestQuery。把validationTimeout设为 5000ms 左右不要低于 1000ms。5.3 maxLifetime 设得比 wait_timeout 还大现象连接池配置看起来没问题但每天固定时间出现一批连接异常。原因maxLifetime设成了 8 小时以上连接在池里活过了 MySQL 的wait_timeout被服务端先掐断。解决maxLifetime必须小于wait_timeout建议留 30 秒以上余量。如果云数据库的wait_timeout是 30 分钟maxLifetime就设 29 分钟。5.4 事务中连接被断开导致数据不一致现象批量更新任务执行到一半报连接断开部分数据已提交部分回滚。原因长事务跨越了wait_timeout或者事务执行期间网络抖动导致连接断开。解决拆分长事务单次事务控制在秒级。对于批量操作用分批提交而不是一个大事务。同时给事务操作加重试但重试前要确认事务是否已提交。5.5 连接池监控指标缺失故障后无法定位现象故障发生了但不知道是连接池耗尽、连接超时还是 SQL 慢查询。原因没有暴露连接池的监控指标。解决HikariCP 自带 Micrometer 指标开启后可以看到活跃连接数、空闲连接数、等待线程数、连接获取时间。关键指标是hikaricp.connections.timeout如果这个值在涨说明连接获取超时需要调大池子或排查慢查询。6. 一个能直接复用的验证脚本与参数速查最后给一个我平时排查这类问题的习惯先写一个最小验证脚本把「空闲 → 超时 → 重连」的完整链路跑一遍确认保活配置真的生效再上生产。下面这个脚本用 Java 直接操作 JDBC不依赖 Spring适合快速验证import java.sql.*; public class MySQLIdleTest { public static void main(String[] args) throws Exception { String url jdbc:mysql://localhost:3306/test?useSSLfalseserverTimezoneUTC; // 先执行一次 try (Connection conn DriverManager.getConnection(url, root, password); Statement stmt conn.createStatement()) { stmt.execute(SELECT 1); System.out.println(First query OK); } // 等待超过wait_timeout测试时把MySQL的wait_timeout设为60秒 System.out.println(Sleeping 70 seconds...); Thread.sleep(70000); // 再执行一次观察是否抛异常 try (Connection conn DriverManager.getConnection(url, root, password); Statement stmt conn.createStatement()) { ResultSet rs stmt.executeQuery(SELECT 1); rs.next(); System.out.println(Second query OK, connection is alive); } catch (SQLException e) { System.out.println(Connection failed: e.getMessage()); } } }这个脚本故意不复用连接每次新建所以它验证的是「新建连接是否正常」。如果你想验证连接池的保活需要把连接池的getConnection()拿到的连接归还后再借出。参数速查表参数位置建议值说明wait_timeoutMySQL默认28800非交互连接空闲超时interactive_timeoutMySQL默认28800交互连接空闲超时maxLifetimeHikariCP小于wait_timeout连接最大存活keepaliveTimeHikariCP300000心跳间隔idleTimeoutHikariCP600000空闲回收validationTimeoutHikariCP5000验活超时read_timeoutpymysql30socket读超时write_timeoutpymysql30socket写超时我自己的习惯是任何新服务上线前先把wait_timeout临时改成 60 秒跑一遍空闲测试确认连接池保活生效后再改回默认值。这个动作花 10 分钟能省掉后面无数个凌晨告警。希望帮到你。本文还有配套的精品资源点击获取 MySQL连接空闲8小时自动断开：连接池保活与重试策略实战
简介这份PDF文档面向使用MySQL数据库与c3p0连接池的Java后端开发者聚焦于连接空闲超过8小时后被MySQL自动断开、而连接池仍误判其有效并返回给客户端导致抛异常的典型故障。文档系统梳理了三种解决思路调整MySQL的wait_timeout与interactive_timeout参数、缩短连接池maxIdleTime使其小于数据库超时时间、以及通过preferredTestQuery与idleConnectionTestPeriod定期检测连接有效性并给出Spring配置文件中数据源bean的具体写法。资源包共1个PDF文件大小约45KB内容紧凑涵盖参数说明、配置示例与排错要点便于快速查阅与落地。目前已有7951人学习下载适合需要排查连接失效问题、优化连接池配置的开发者参考可帮助读者理解超时机制、掌握配置调整方法并减少生产环境中的连接异常。1. MySQL 连接空闲 8 小时后自动断开一个被低估的线上故障源头凌晨两点告警群炸了。一个跑了半年的定时任务突然开始报Communications link failure重启服务就好过一夜又挂。翻代码没改过翻数据库没重启过最后定位到一条冷知识MySQL 默认的wait_timeout是 28800 秒也就是 8 小时。连接池里的空闲连接一旦超过这个阈值服务端单方面掐断而客户端还以为这条连接活着下次借出去执行 SQL 就直接翻车。这不是玄学是 TCP 连接生命周期和 MySQL 会话管理之间一个非常具体的错位。这个问题的核心不是「MySQL 为什么会断开」而是「断开之后你的应用为什么不知道」。连接池、ORM 框架、驱动层各自有各自的保活策略配错一个参数就会在业务低峰期埋雷。下面按「先搞懂断开机制 → 再选保活方案 → 落到代码和参数 → 排掉常见坑」的顺序讲清楚适合后端开发、运维和正在搭连接池的工程师。2. 先搞清楚 MySQL 到底在什么条件下掐断连接2.1 wait_timeout 和 interactive_timeout 的真实作用范围MySQL 服务端有两个控制空闲连接的超时参数名字很像但作用对象不同。wait_timeout管的是非交互式连接也就是你的应用通过 JDBC、连接池建立的普通连接interactive_timeout管的是交互式连接比如你用 mysql 命令行客户端登进去敲 SQL 的那种会话。两个参数默认值都是 28800 秒。关键点在于连接池里的连接属于非交互式受wait_timeout约束。很多人改了interactive_timeout发现没用就是因为改错了对象。查看当前值的命令SHOW VARIABLES LIKE %timeout%;输出里会同时看到wait_timeout和interactive_timeout。如果你只想临时验证可以会话级设置SET SESSION wait_timeout 60;这条命令只影响当前会话断开重连就恢复全局值。要永久生效得改配置文件my.cnf的[mysqld]段然后重启或SET GLOBAL。但注意调大wait_timeout只是把雷埋得更深不是解决方案。因为网络中间设备防火墙、负载均衡也可能有自己的空闲超时你不可能无限调大。2.2 连接被掐断时客户端为什么毫无感知TCP 连接断开分两种一种是服务端发 FIN 包正常关闭客户端能收到另一种是服务端直接发 RST 或者中间设备静默丢包客户端完全不知道。MySQL 的wait_timeout到期后服务端会关闭会话但这个关闭动作不一定能及时通知到客户端尤其是连接经过多层网络设备时。更麻烦的是连接池的检测机制。连接池借出连接前通常会做一个validationQuery比如SELECT 1来验活但如果连接池配置的是「借出时不检测」或者「检测间隔太长」就会把一条已经死掉的连接交给业务代码。业务代码拿到连接执行 SQL第一次写操作可能成功因为 TCP 缓冲区还没报错第二次才抛异常。这就是为什么很多故障表现为「偶发」「重启就好」「过一段时间又出现」。理解这一点之后解决思路就清晰了要么让连接池主动淘汰空闲超时的连接要么让连接自己定期发心跳保持活跃要么在借出时强制验活。三种方案各有适用场景下面逐个拆。3. 连接池保活方案从 JDBC 参数到 HikariCP 配置3.1 JDBC URL 里的 autoReconnect 为什么不该用很多老教程会告诉你加autoReconnecttrue这个参数在 MySQL Connector/J 里确实存在但官方文档明确不推荐。原因是它只在执行 SQL 抛异常后才触发重连而且会丢失会话状态临时表、事务、用户变量全没了。更危险的是它可能让事务在不知情的情况下被重放或部分提交。正确的做法是在连接池层面解决而不是在驱动层。下面以目前主流的 HikariCP 为例给出一个能扛住 8 小时空闲的配置。3.2 HikariCP 的关键参数与完整配置示例HikariCP 有几个参数直接决定空闲连接会不会被服务端掐死参数建议值作用maxLifetime比wait_timeout小 30 秒以上连接最大存活时间到期主动关闭重建idleTimeout小于wait_timeout空闲连接回收时间keepaliveTime小于wait_timeout定期发送心跳包保活validationTimeout5000ms验活超时connectionTestQuerySELECT 1验活 SQLJDBC4 驱动可省略一个可抄的 Spring Boot 配置spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 idle-timeout: 600000 # 10分钟远小于8小时 max-lifetime: 1740000 # 29分钟比wait_timeout小 keepalive-time: 300000 # 5分钟发一次心跳 connection-timeout: 30000 validation-timeout: 5000 connection-test-query: SELECT 1max-lifetime设成 1740000 毫秒29 分钟是有讲究的MySQL 默认wait_timeout是 8 小时但很多云数据库会把它调到更短比如 30 分钟。设 29 分钟能保证连接在服务端掐断之前就被连接池主动回收重建。keepalive-time则是给空闲连接发心跳防止被中间网络设备判定为死连接。注意keepalive-time只在 HikariCP 4.0.0 及以上版本支持老版本没有这个参数只能靠max-lifetime和idle-timeout配合。3.3 用代码验证保活是否真的生效配完不能只看日志要实际验证。写一个简单的测试让连接空闲超过wait_timeout再执行查询// 模拟连接空闲后执行SQL SpringBootTest public class ConnectionKeepAliveTest { Autowired private DataSource dataSource; Test public void testIdleConnection() throws Exception { // 先拿一条连接执行一次 try (Connection conn dataSource.getConnection(); Statement stmt conn.createStatement()) { stmt.execute(SELECT 1); } // 等待超过wait_timeout测试环境可临时设为60秒 Thread.sleep(70000); // 再次获取连接执行 try (Connection conn dataSource.getConnection(); Statement stmt conn.createStatement()) { ResultSet rs stmt.executeQuery(SELECT 1); assertTrue(rs.next()); } } }这个测试的逻辑是第一次执行后连接归还池中等待超过服务端超时时间再借出连接。如果保活配置正确第二次执行不会抛Communications link failure。测试时可以把 MySQL 的wait_timeout临时设为 60 秒来加速验证但记得测完改回去。4. 不用连接池的场景手动保活与重试策略4.1 定时任务里的连接管理有些场景没有连接池比如 Python 脚本、定时任务、数据同步工具。这时候需要手动管理连接生命周期。核心原则是不要长期持有一条连接用完就关下次重连。如果业务要求保持长连接那就加心跳。Python 的pymysql示例import pymysql import time def get_connection(): return pymysql.connect( hostlocalhost, userroot, passwordpassword, databasetest, connect_timeout10, read_timeout30, write_timeout30 ) def keep_alive_loop(): conn get_connection() while True: try: # 每5分钟发一次心跳 with conn.cursor() as cursor: cursor.execute(SELECT 1) cursor.fetchall() time.sleep(300) except pymysql.err.OperationalError as e: # 连接断开重连 print(fConnection lost: {e}, reconnecting...) conn get_connection()read_timeout和write_timeout是关键参数它们控制 socket 层面的超时避免连接已经死了但程序还在傻等。心跳间隔设 300 秒远小于 MySQL 的 8 小时也小于大多数防火墙的空闲超时。4.2 重试逻辑怎么写才不会雪崩连接断开后重试是必须的但重试策略不对会引发雪崩。三个原则限制重试次数、加退避间隔、区分可重试异常。public T T executeWithRetry(SupplierT action, int maxRetries) { int attempt 0; while (true) { try { return action.get(); } catch (CommunicationsException | SQLTransientConnectionException e) { attempt; if (attempt maxRetries) { throw e; } // 指数退避最多等2秒 long backoff Math.min(1000L * (1L attempt), 2000L); try { Thread.sleep(backoff); } catch (InterruptedException ie) { Thread.currentThread().interrupt(); throw new RuntimeException(ie); } } } }这里只捕获CommunicationsException和SQLTransientConnectionException这类连接层异常不捕获业务 SQL 异常。因为业务异常重试可能导致重复插入。退避时间用指数增长但设上限避免大量请求同时重试把数据库打挂。5. 避坑与排查那些让你白忙半天的细节5.1 改了 wait_timeout 但连接还是断现象把 MySQL 的wait_timeout调到 24 小时应用连接还是过一段时间就断。原因中间有防火墙或负载均衡它们有自己的空闲超时通常比 MySQL 短。TCP 连接在中间设备上被静默丢弃两端都不知道。解决不要依赖调大wait_timeout而是在连接池配keepaliveTime或maxLifetime让连接主动重建。同时检查网络设备的空闲超时配置。5.2 连接池验活 SQL 配了但没生效现象配了connectionTestQuery: SELECT 1但故障依旧。原因HikariCP 在 JDBC4 驱动下默认用Connection.isValid()而不是执行 SQLconnectionTestQuery可能被忽略。另外如果validationTimeout设得太短验活本身超时也会被跳过。解决确认驱动版本必要时强制指定connectionTestQuery。把validationTimeout设为 5000ms 左右不要低于 1000ms。5.3 maxLifetime 设得比 wait_timeout 还大现象连接池配置看起来没问题但每天固定时间出现一批连接异常。原因maxLifetime设成了 8 小时以上连接在池里活过了 MySQL 的wait_timeout被服务端先掐断。解决maxLifetime必须小于wait_timeout建议留 30 秒以上余量。如果云数据库的wait_timeout是 30 分钟maxLifetime就设 29 分钟。5.4 事务中连接被断开导致数据不一致现象批量更新任务执行到一半报连接断开部分数据已提交部分回滚。原因长事务跨越了wait_timeout或者事务执行期间网络抖动导致连接断开。解决拆分长事务单次事务控制在秒级。对于批量操作用分批提交而不是一个大事务。同时给事务操作加重试但重试前要确认事务是否已提交。5.5 连接池监控指标缺失故障后无法定位现象故障发生了但不知道是连接池耗尽、连接超时还是 SQL 慢查询。原因没有暴露连接池的监控指标。解决HikariCP 自带 Micrometer 指标开启后可以看到活跃连接数、空闲连接数、等待线程数、连接获取时间。关键指标是hikaricp.connections.timeout如果这个值在涨说明连接获取超时需要调大池子或排查慢查询。6. 一个能直接复用的验证脚本与参数速查最后给一个我平时排查这类问题的习惯先写一个最小验证脚本把「空闲 → 超时 → 重连」的完整链路跑一遍确认保活配置真的生效再上生产。下面这个脚本用 Java 直接操作 JDBC不依赖 Spring适合快速验证import java.sql.*; public class MySQLIdleTest { public static void main(String[] args) throws Exception { String url jdbc:mysql://localhost:3306/test?useSSLfalseserverTimezoneUTC; // 先执行一次 try (Connection conn DriverManager.getConnection(url, root, password); Statement stmt conn.createStatement()) { stmt.execute(SELECT 1); System.out.println(First query OK); } // 等待超过wait_timeout测试时把MySQL的wait_timeout设为60秒 System.out.println(Sleeping 70 seconds...); Thread.sleep(70000); // 再执行一次观察是否抛异常 try (Connection conn DriverManager.getConnection(url, root, password); Statement stmt conn.createStatement()) { ResultSet rs stmt.executeQuery(SELECT 1); rs.next(); System.out.println(Second query OK, connection is alive); } catch (SQLException e) { System.out.println(Connection failed: e.getMessage()); } } }这个脚本故意不复用连接每次新建所以它验证的是「新建连接是否正常」。如果你想验证连接池的保活需要把连接池的getConnection()拿到的连接归还后再借出。参数速查表参数位置建议值说明wait_timeoutMySQL默认28800非交互连接空闲超时interactive_timeoutMySQL默认28800交互连接空闲超时maxLifetimeHikariCP小于wait_timeout连接最大存活keepaliveTimeHikariCP300000心跳间隔idleTimeoutHikariCP600000空闲回收validationTimeoutHikariCP5000验活超时read_timeoutpymysql30socket读超时write_timeoutpymysql30socket写超时我自己的习惯是任何新服务上线前先把wait_timeout临时改成 60 秒跑一遍空闲测试确认连接池保活生效后再改回默认值。这个动作花 10 分钟能省掉后面无数个凌晨告警。希望帮到你。本文还有配套的精品资源点击获取