K8s 滚动发布时 HikariCP close() 对 in-flight 慢 SQL 是「中断」还是「死等」？graceful shutdown 到底该给慢查询留多长 drain 预算？

背景 订单服务，Spring Boot 3.2 + JDK 17 + HikariCP 5.1.0 + MySQL 8.0，K8s 1.28 滚动发布（maxUnavailable=1、terminationGracePeriodSeconds=60，preStop sleep 10s 等摘流）。有 2~3 条慢 SQL 卡在 in-flight，导致 shutdown 时发生连接中断或服务不可用。

现象

• 滚动发布时，Pod 优雅退出过程中，慢 SQL 未被及时中断，导致 shutdown 超时；
• 有 2~3 条慢 SQL 卡在 in-flight，服务端连接池（HikariCP）在 close() 时表现不一致：
  • 有些 SQL 被中断，有些则继续执行完成；
  • 服务端日志显示部分慢 SQL 在 shutdown 期间被强制中断，但有部分仍继续执行。

已尝试的排查与结果

• 检查 HikariCP 配置（如 idleTimeout、maxLifetime、connectionTimeout 等），未发现明显配置问题；
• 检查 MySQL 的 slow query log，发现部分慢 SQL 实际执行时间超过 30s；
• 检查 K8s 的 terminationGracePeriodSeconds 设置为 60s，preStop 脚本 sleep 10s 后执行 shutdown；
• 检查服务日志，发现部分慢 SQL 在 shutdown 期间被强制中断，但有部分仍继续执行，导致 shutdown 超时。

期望的答案形态

1. HikariCP 的 close() 在遇到 in-flight 慢 SQL 时是「中断」还是「死等」？
2. 如果是「中断」，是否可以通过配置控制该行为？
3. 如果是「死等」，graceful shutdown 时应该给慢查询预留多长 drain 预算？
4. 是否有实际案例或最佳实践，说明如何在 K8s 滚动发布时优雅关闭 HikariCP 连接池，避免慢 SQL 导致 shutdown 超时？