Java中解决MySQL锁等待超时需从源头控制：①缩短事务边界，剥离非DB操作；②优化SQL与索引，避免全表扫描和间隙锁；③主动监控INNODB_TRX并Kill阻塞事务；④合理调整超时值并按业务分级重试。
Java 中通过 JDBC 处理长事务导致的 MySQL 锁等待超时（Lock wait timeout exceeded; try restarting transaction），核心不是“捕获后重试”就完事，而是从源头控制锁持有时间、避免阻塞、快速定位问题。以下四类做法最实用、最贴近生产环境。
缩短事务边界，剥离非数据库操作
长事务往往不是 SQL 慢，而是事务里混入了耗时的外部动作。JDBC 事务一旦开启（setAutoCommit(false)），锁就从第一条 DML 开始持有，直到 commit() 或 rollback() —— 中间任何网络调用、文件读写、复杂计算都会让锁“悬空”几十秒。
- 把远程 HTTP 调用、消息发送、日志落盘等移出
try (connection) { ... commit() }块 - 只在真正需要 ACID 保障的 DB 操作段开启事务，例如：“扣库存 + 写订单”必须原子，但“发短信通知”可以异步补发
- 使用 Spring 的
@Transactional(propagation = Propagation.REQUIRED)时，确保方法体轻量；若需耗时处理，拆成两个事务方法，中间显式提交
优化 SQL 与索引，缩小锁粒度
没走索引的 UPDATE/DELETE 很可能触发全表扫描+表级锁升级，或引发大量间隙锁（Gap Lock），让本该行级并发的操作变成串行排队。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 对 WHERE 条件字段（如
user_id、order_no）务必建联合索引，尤其注意最左前缀匹配 - 用
EXPLAIN检查执行计划：是否type=ALL（全表扫描）、key=NULL（未命中索引） - 避免在事务中执行
SELECT ... FOR UPDATE后长时间停留；如必须加锁，尽量用UPDATE ... WHERE替代先查再更
主动监控与快速干预
线上出现锁超时，不能只靠重启应用。JDBC 层可配合数据库诊断能力，做到“快发现、快止损”。
立即学习“Java免费学习笔记（深入）”；
- 在报错日志中提取 SQL 和线程 ID，立即执行：
SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started DESC LIMIT 5;
查看trx_state（是否 RUNNING）、trx_wait_started（是否卡住）、trx_query（当前执行语句） - 对长时间未提交事务（如
trx_started超过 30 秒），用KILL [trx_mysql_thread_id]主动终止，防止雪崩 - 在 Druid/HikariCP 连接池配置中开启
phyTimeoutMillis和leakDetectionThreshold，辅助识别连接泄漏导致的隐式长事务
合理调整与降级策略
临时调大超时值只是缓冲手段，但某些场景下仍有必要作为兜底：
- 全局调整（需 DBA 审批）：
SET GLOBAL innodb_lock_wait_timeout = 120;（单位秒）
或在my.cnf中持久化：[mysqld]innodb_lock_wait_timeout = 120 - 会话级覆盖（推荐用于特定业务）：
在获取连接后、执行关键 SQL 前执行：connection.createStatement().execute("SET innodb_lock_wait_timeout = 60"); - Java 层捕获异常后，不盲目重试，而是结合业务判断：库存类操作可重试 1–2 次；支付类操作应记录失败并人工介入
