模板查询超时和事务超时同时存在时，不能自行假定框架取两个数字的最小值。先查看传入 Statement 的设置，再观察实际驱动如何执行取消和释放资源。
前置：JDBC 与连接池、工具取消与迟到结果。以下配置与慢查询实验均未运行。
剩余事务超时优先
JdbcTemplate.setQueryTimeout 的单位是秒，默认 -1 表示不向驱动传入特定查询超时值，而使用驱动默认。若在配置了事务超时的事务内执行，该值会被“剩余事务超时”覆盖。DataSourceUtils.applyTimeout 的契约也明确说明事务超时优先覆盖传入值。因此不能把模板设为 1 秒就当成所有事务中的 SQL 必然有 1 秒上限，也不能自行假定框架会计算 min(模板值, 事务剩余值)。这是同一项目的 API 契约相互印证，不是独立数据库行为验证。
把连接获取、事务剩余预算、Statement 查询超时、HTTP 调用方等待时限分别记录。外层停止等待不等于 SQL 或连接占用已经结束。此处只新增“SQL 超时配置的覆盖顺序”，不重复既有取消与重试规则；事务是否真正生效及是否加入既有事务也必须纳入测试前提。
第一层验收 实际传入的设置
在隔离测试环境创建专用 JdbcTemplate 并设置 setQueryTimeout(1)，使用绑定同一 DataSource 的 TransactionTemplate，设置 setTimeout(10)。通过可记录 JDBC 调用的测试代理，分别执行无事务查询、事务开始后立即查询、事务经过部分时间后查询，记录实际传入 Statement.setQueryTimeout 的秒数及调用顺序。验收重点是证明配置覆盖关系，不把墙钟精度或某个剩余整数写死为断言；不要运行时修改多个请求共享的模板配置。
第二层验收 驱动与数据库行为
再用项目实际 MySQL 版本和 JDBC 驱动执行隔离慢查询，记录超时异常、实际耗时、数据库端语句是否仍在执行、连接归还时间；不可在生产制造慢查询。框架契约不能证明所有驱动取消能力、网络阻塞处理或事务整体硬截止时间。实际依赖与驱动版本需在运行记录中列明；这里没有提供已通过的数据库实验结果。
来源与版本
Spring Framework 7.0.10。资料原核查时间为 2026 年 10 月 29 日 12:06 JST，独立发布日期未核实。来源：JdbcTemplate setQueryTimeout、DataSourceUtils applyTimeout。