问MySQL 主备切换后部分线程卡住十几分钟，连接池该如何配置？

场景：订单服务部署在 TKE 上，Java 17 + Spring Boot 3 + HikariCP 5，通过内网地址连接云数据库 MySQL 8.0 双节点实例。每季度做一次主备切换演练。

现象：

1. 控制台发起主备切换后，大部分请求在 30 秒内恢复，新建的连接都正常。
2. 每个 Pod 总有少量线程卡在 socketRead0，大约 15 分钟后才抛出 CommunicationsException。这期间它们占着的连接一直是 active，Hikari 的 active 指标居高不下，接口 P99 被拉高。
3. 演练时在 Pod 里抓包，这些连接上客户端一直在重传，没有收到任何回包，也没有 RST。

已尝试：

1. 把 Hikari 的 maxLifetime 从 30 分钟改成 10 分钟，没有改善，正在执行的查询不受它影响。
2. connectionTimeout=3000 只对获取连接生效，对已经卡住的读没有作用。
3. 考虑在 JDBC URL 里加 socketTimeout，但有几条报表查询本来就要跑 1 到 2 分钟，担心被误杀。

问题：

1. 卡 15 分钟左右，是不是 Linux net.ipv4.tcp_retries2 默认值决定的重传上限？在 Pod 里单独调小这个参数是否可行，有什么副作用？
2. socketTimeout 和 MySQL 侧的 max_execution_time 应该怎么分工，才能既尽快发现死连接，又不误杀正常的长查询？
3. 除了调超时，有没有更通用的办法（例如 TCP_USER_TIMEOUT、TCP keepalive，或者按查询类型拆连接池），让连接池在主备切换后尽快剔除这类连接？