MySQL连接池存在无效连接时读写请求的处理逻辑问询

这个行为没有统一的通用标准，完全由你使用的连接池组件的具体实现和配置决定，可分为两类常见情况：

1. 未开启连接有效性校验（多数连接池默认配置） #

会直接返回错误。
默认状态下连接池为了降低额外性能损耗，不会在每次借出连接前主动校验有效性。如果节点宕机、主从切换后缓存的连接已经失效，业务请求拿到无效连接执行读写操作时，会直接抛出通信链路错误，比如MySQL侧常见的Communications link failure报错。

2. 已开启连接有效性校验 #

会自动销毁无效连接、创建新连接后再处理请求，不会直接报错。
不同连接池的校验触发逻辑不同，常见的可配置校验规则如下：

• 借出连接前实时校验：比如HikariCP的connectionTestQuery配置项、Druid连接池的testOnBorrow开关，每次业务请求拿连接时，先执行简单校验语句（通常是SELECT 1），如果连接失效直接销毁，重新创建有效连接再返回给业务层。
• 后台异步空闲校验：比如HikariCP的keepaliveTime配置、Druid的testWhileIdle开关，后台线程定期扫描空闲连接，提前销毁失效连接，尽可能避免业务线程拿到无效连接。

特殊注意事项 #

就算开启了常规连接校验，也存在两类极端场景仍会报错：

• 校验刚完成、SQL实际执行前的极短时间内节点宕机，校验结果已经过期，此时执行SQL仍会失败，建议业务层针对核心场景添加少量SQL执行失败重试逻辑兜底。
• 主节点迁移后旧主节点转为只读状态，此时旧主的TCP连接仍然存活，常规的SELECT 1校验无法识别该异常，业务写请求发送到旧主时会报The MySQL server is running with the --read-only option so it cannot execute this statement错误，这类问题需要配合读写分离路由策略、集群VIP漂移或者连接池的只读节点识别逻辑处理。

内容的提问来源于stack exchange，提问作者venkat