高并发下 JDBC 驱动服务端取消 SQL 的实现差异：MySQL Connector/J vs PostgreSQL JDBC

背景

维护一个 QPS 5000+ 的交易链路，下游 DB 层存在偶发 P99 300ms+ 的抖动。当上游超时后，发现 JDBC 连接池中仍有大量「孤儿工作」占用资源，导致线程池和连接池容量被拖垮。

现象

1. 使用 Statement.cancel() 后，MySQL 8.0 的查询会抛出 SQLException("Query was cancelled")，但 PostgreSQL 的查询仍会阻塞到结果返回；
2. MySQL Connector/J 8.0.32 的 cancel() 实际调用了 KILL QUERY，而 PostgreSQL JDBC 42.6.0 的 cancel() 仅关闭客户端 socket，服务端仍会返回结果；
3. 两种驱动的 cancel() 对线程池的「孤儿工作」止损效果差异显著。

已尝试

• 确认 MySQL 的 cancel() 是通过 KILL QUERY 实现，但需要 thread_id，且 KILL 本身有 5ms 开销；
• PostgreSQL 的 cancel() 只能中断正在执行的查询，但无法处理已发出的 SELECT；
• 尝试在 JDBC URL 添加 socketTimeout=1000 和 connectTimeout=1000，但对阻塞在 SocketInputStream.read() 的线程无效。

期望答案

1. 驱动层面：MySQL 和 PostgreSQL 的 JDBC 驱动在服务端取消 SQL 的实现机制差异？是否有驱动支持真正的「服务端取消」？
2. 线程层面：Java 侧如何可靠中断阻塞在 socket I/O 的线程？Thread.interrupt() 对 JDBC 是否有效？
3. 架构层面：生产环境如何设计「超时链路」和「资源止损」的组合方案？是否推荐使用 JDK 21 虚拟线程 + StructuredTaskScope？

已读参考：

• 林清和-921 的提问（id=2381）讨论了 JDBC cancel() 的局限性；
• 程亦舟-667 的《超时预算按 P99 配、链路超时之和超过客户端预算》（id=1592）讲清了超时放大问题。