事务超时时间需分层设定：核心写操作5–15秒，后台批量任务30–300秒或不限时（配监控），只读查询≤3秒；sql超时应比事务超时小2–3秒；须避免事务内远程调用等耗时操作，并通过压测、apm和数据库锁监控验证效果。
事务超时时间设得太短，容易误回滚；设得太长，又可能长期占着数据库连接和锁，拖垮系统。合理设置的关键不是找一个“万能值”，而是结合业务特征、SQL性能和系统承载能力分层控制。
看业务场景定基础时长
不同操作对响应要求差异很大：
- 用户注册、下单等核心写操作：建议 5–15 秒。这类流程通常含校验、库存扣减、日志落库等，需留出缓冲但不能久拖
- 后台批量任务（如日终对账、报表生成）：可设 30–300 秒，甚至关闭超时（timeout = -1），但必须配合进度监控和人工干预机制
- 只读查询（如列表页、详情页）：一般不开启事务，若必须加
@Transactional(readOnly = true)，超时建议 ≤ 3 秒
盯住 SQL 实际执行耗时
事务超时 ≠ SQL 超时，但后者是前者的最大组成部分。如果某条 SQL 平均要跑 8 秒，那事务 timeout 设 10 秒就非常危险——稍有波动就超时。
- 用 MyBatis 的
timeout属性 或defaultStatementTimeout单独控单条 SQL，推荐比事务 timeout 小 2–3 秒 - 在数据库侧查慢 SQL：MySQL 执行
SHOW FULL PROCESSLIST或分析 slow log；PostgreSQL 查pg_stat_statements - 避免在事务里做远程调用、文件读写、复杂计算——这些会把事务时钟白白耗掉
用好分层超时配置
别只靠一个 @Transactional(timeout=10) 硬扛所有情况：
-
全局兜底：Spring Boot 配置
spring.transaction.default-timeout=10，覆盖所有未显式设 timeout 的方法 -
按方法粒度覆盖：对已知慢的方法单独加大，比如
@Transactional(timeout = 60)标在导出接口上 -
编程式动态控制：对用户可选参数（如导出范围）导致耗时不确定的场景，用
TransactionTemplate.setTimeout()运行时计算后设置
验证和监控不能少
设完不验证，等于没设：
- 压测时重点观察
TransactionTimedOutException报错频次，结合 APM 工具（如 SkyWalking、Pinpoint）看事务实际耗时分布 - 数据库端检查锁等待：MySQL 查
information_schema.INNODB_TRX和INNODB_LOCK_WAITS，确认是否真因锁导致超时，而非业务逻辑卡顿 - 日志里加关键标记：在事务入口打
START TX [method] at {}，出口打END TX in {}ms，便于快速归因
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
