高并发下 JDBC 驱动取消 SQL 的实现差异：MySQL Connector/J 与 PostgreSQL JDBC 如何避坑？

【背景】 在高并发场景下，JDBC 驱动服务端取消 SQL 是常见需求（如超时/中断/取消），但 MySQL Connector/J 和 PostgreSQL JDBC 的实现差异容易引发踩坑。

【常见分歧】

1. MySQL Connector/J：通过 cancel() 方法触发取消，但需配合 Statement 级别超时（queryTimeout），且取消后可能残留连接；
2. PostgreSQL JDBC：使用 cancel() + interrupt() 双重机制，但需注意事务隔离级别对取消行为的影响。

【我的倾向】 更推荐 PostgreSQL JDBC 的「主动中断 + 事务感知」方案，因能更精确控制取消粒度，但需注意其对连接池的额外压力。

【想听你的观点】

• 你们线上用哪种实现？遇到过哪些边界场景的诡异行为？
• 对「取消 SQL」的可靠性要求 vs 系统资源占用，如何取舍？