setQueryTimeout(int seconds)是唯一可靠方式，必须在execute前调用，单位为秒，0表示无限制；它在客户端启动独立定时器中断慢SQL，而connectTimeout、socketTimeout等参数仅作用于连接建立或网络层，无法控制SQL执行超时。
在 JDBC 中设置查询超时时间，核心是调用 Statement 或 PreparedStatement 的 setQueryTimeout(int seconds) 方法——它是在客户端启动独立定时器的唯一可靠方式，能真正中断执行中的慢 SQL。
必须在 execute 前设置，且单位是秒
这个方法必须在 executeQuery()、executeUpdate() 等执行方法调用之前设置，之后调用无效。参数单位是**秒**（不是毫秒），传入 0 表示不设超时（默认行为），传入 10 就代表 10 秒后强制终止。
- MySQL 驱动会启动一个异步线程，在超时后尝试通过新连接发送
KILL QUERY命令 - Oracle 驱动（ojdbc8+）则直接关闭底层 Socket 并抛出
SQLException（如 ORA-17127） - PostgreSQL 和 SQL Server 驱动也遵循相同语义，但具体中断机制略有差异
别混淆其他“超时”参数
JDBC URL 或连接池里常见的几个超时参数，作用范围完全不同，不能替代 setQueryTimeout：
-
connectTimeout：只管建立初始 TCP 连接，单位毫秒；对已连上后的 SQL 执行无影响 -
socketTimeout（或oracle.jdbc.ReadTimeout）：只在等待网络数据包到达时计时，一旦数据库返回首行元数据就停止计时，无法拦截 PL/SQL 循环卡死或大结果集 fetch 慢 -
connection-timeout（如 HikariCP）：控制从连接池获取连接的等待时间，和 SQL 执行无关
Spring 场景下的推荐配置方式
避免全局硬编码，按业务类型分级设置更稳妥：
立即学习“Java免费学习笔记（深入）”；
-
JdbcTemplate：定义 Bean 时直接调用
setQueryTimeout(5)，适用于事务内 DML -
MyBatis：在
<select>标签中加timeout="60"属性，底层仍转为setQueryTimeout -
原生 JDBC：每次创建
PreparedStatement后立即设置，不要漏掉 - 报表类查询可设 60 秒，核心交易类建议 3–5 秒，避免拖垮整体响应
常见失效原因要避开
加了超时却没效果？大概率掉进了这几个坑：
- 方法被同一类内调用，绕过了 Spring 代理，
@Transactional或超时逻辑根本没生效 - 超时设置写在
execute之后，JDBC 驱动直接忽略 - 事务传播行为用了
NOT_SUPPORTED，导致当前方法实际不在事务上下文中，超时设置形同虚设 - SQL 已在数据库端卡死（如锁等待、全表扫描），而驱动未成功发出 cancel 请求（老版本驱动兼容性问题）
