MySQL事务锁超时后不会自动重试或回滚，仅中断当前语句并抛出错误，事务仍处于活动状态，需应用层显式ROLLBACK或COMMIT；否则继续执行将引发新错误或数据不一致。
MySQL事务锁超时后不会自动重试，只会抛出异常
MySQL本身不提供事务锁超时后的自动重试、回滚后重执行或静默续租锁的机制。一旦innodb_lock_wait_timeout触发（默认50秒），当前语句直接报错，事务停留在“活动但未提交”状态，需应用层显式处理。
常见错误现象：ERROR 1205 (40001): Deadlock found when trying to get lock 或 ERROR 1205 (40001): Lock wait timeout exceeded —— 这两类错误都意味着事务已被中断，但连接仍处于活跃会话中，SELECT @@in_transaction 返回 1，不手动ROLLBACK就继续执行其他语句，大概率触发ERROR 1399 (XAE07): XAER_RMFAIL或数据不一致。
- 锁超时 ≠ 事务自动回滚：InnoDB只中断当前阻塞语句，事务本身仍 open，必须由客户端发
ROLLBACK或COMMIT - 应用若忽略错误继续用同一连接执行新语句，MySQL会拒绝（报
ERROR 1305 (42000): SAVEPOINT does not exist之类）或静默失败（取决于驱动行为） - Java JDBC、Python PyMySQL/MySQLdb 等驱动默认不自动
ROLLBACK，需在catch块里手动调用conn.rollback()
如何配置锁等待超时时间：全局 vs 会话级
innodb_lock_wait_timeout 控制的是「等待行锁释放」的最长时间，不是事务总耗时限制（那是wait_timeout或max_execution_time的事）。它既可设为全局变量，也能在单个会话中动态调整，但要注意作用域和权限。
- 全局设置（需 SUPER 权限）：
SET GLOBAL innodb_lock_wait_timeout = 30;—— 影响后续新建连接，已存在的会话不受影响 - 会话级设置（推荐）：
SET SESSION innodb_lock_wait_timeout = 10;—— 只对当前连接生效，适合短时高并发写场景临时降级容忍度 - 不能在事务中途中修改：执行
SET前必须确保不在事务内，否则报ERROR 1305 (42000): SAVEPOINT does not exist - 值太小（如1）易导致正常争抢被误杀；太大（如300）会让故障线程卡更久，拖垮连接池
应用层捕获与处理锁超时异常的关键点
不同语言驱动对Lock wait timeout exceeded的封装不同，但核心都是识别 SQLSTATE 40001 或 MySQL 错误码 1205（死锁）和 1205以外的1205变体（实际是1205和1205之外的1205？注意：MySQL 8.0+ 中锁超时固定为错误码 1205，但消息文本不同，应同时匹配错误码和消息关键词）。
- Python（PyMySQL）示例：
try: cursor.execute("UPDATE accounts SET balance = balance - 100 WHERE id = 1") except pymysql.err.OperationalError as e: if e.args[0] == 1205 and "Lock wait timeout" in str(e): conn.rollback() # 这里加重试逻辑（最多2次） else: raise - Java（JDBC）要检查
SQLException.getSQLState()是否为"40001"，而非只看getErrorCode()，因某些中间件会转义错误码 - 不要依赖
sleep()后立即重试：多个线程同时退避再冲，可能再次碰撞。建议用指数退避（如 100ms → 300ms → 900ms） - 重试前务必
ROLLBACK：否则下一次BEGIN或隐式开启事务会失败
容易被忽略的底层细节：锁超时不释放 gap lock，也不清空 undo log
锁超时只中断等待动作，不会主动清理事务持有的任何锁（包括gap lock、next-key lock），也不会释放undo页。这意味着：即使你已经收到超时错误并ROLLBACK，若之前事务写过数据，其undo记录仍保留在undo log中，直到purge线程回收。
- 后果：长事务 + 频繁锁超时 → undo log 膨胀 →
INFORMATION_SCHEMA.INNODB_TRX里看到trx_state = 'LOCK WAIT'已消失，但trx_rows_locked可能仍很高 - 排查方法：
SELECT * FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE '%undo%';观察undo_log_pages_written增长速率 - 真正释放锁的唯一时机是显式
COMMIT或ROLLBACK，超时本身不构成“事务结束”的信号 - 所以应用层
ROLLBACK之后，最好再查一次SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_mysql_thread_id = CONNECTION_ID();确认事务已退出
锁超时不是MySQL帮你兜底的开关，而是它把问题甩给你的明确信号——什么时候重试、重试几次、要不要降级、怎么避免雪崩，全得你在代码里一条条写清楚。最常漏掉的，就是以为报错了事务就结束了。
