会话级锁等待超时通过SET SESSION innodb_lock_wait_timeout = N设置，仅对当前连接生效且不可超过GLOBAL值，单位秒，最小为1，生产建议3–10秒。
如何设置会话级锁等待超时（innodb_lock_wait_timeout）
MySQL 的锁等待超时不是靠“会话中断”控制的，而是由 innodb_lock_wait_timeout 参数决定——它只控制事务在等待行锁时最多忍多久，超时就抛 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction。这个参数支持会话级动态设置，无需重启 MySQL。
执行以下语句即可为当前连接单独调整：
SET SESSION innodb_lock_wait_timeout = 5;
注意：SET GLOBAL 修改对已存在的连接无效，只影响新建立的连接；SESSION 级别修改仅对当前连接生效，且不能超过 GLOBAL 值（若 GLOBAL 设为 10，SESSION 就不能设成 15）。
- 单位是秒，最小值为 1，生产环境建议设为 3–10，避免长等待拖垮整体响应
- 该设置不解决锁本身，只是让失败更快暴露，必须配合锁排查使用
- ORM 框架（如 MyBatis、Hibernate）通常不自动传播该设置，需在数据源初始化时显式配置或通过 init SQL 注入
为什么不能靠“会话超时”来解决锁等待
会话超时（如 wait_timeout 或应用层的 session timeout）和锁等待超时是两回事：前者是连接空闲多久后断开，后者是事务在等锁时能忍几秒。即使你把 wait_timeout 设成 60 秒，一个卡在锁等待里的事务仍会一直等到 innodb_lock_wait_timeout 触发才报错，不会因为连接“看起来空闲”就被干掉。
典型误判场景：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 应用端设置了 HTTP 请求超时 30s，但 MySQL 层还在等锁，此时客户端已断开，MySQL 连接变成 sleep 状态，事务却没 rollback ——造成隐性长事务
- 误以为
max_execution_time能终止锁等待，但它只限制 SELECT 执行时长，对 UPDATE/DELETE 等加锁操作无效 - 在连接池（如 HikariCP）里配置了
connection-timeout，这只影响获取连接阶段，不干预已获取连接上的事务行为
自动处理锁等待的可行路径
真正能“自动处理”的方式，是让系统在超时发生前主动干预或事后快速清理，而不是依赖被动超时。核心手段只有三个：
- 用
SELECT * FROM information_schema.INNODB_TRX定期扫描运行时间过长的事务（如trx_started早于当前时间 10 秒），结合information_schema.PROCESSLIST找出对应ID，再执行KILL [ID] - 在业务代码中对关键 DML 操作加 try-catch，捕获
MySQLTransactionRollbackException后重试（注意幂等性） - 用
SHOW ENGINE INNODB STATUS\G输出中的LATEST DETECTED DEADLOCK和TRANSACTIONS部分做实时监控，接入 Prometheus + Alertmanager 实现告警
没有“全自动 kill 锁等待事务”的内置机制——MySQL 不会因为你设了 innodb_lock_wait_timeout=5 就提前帮你 kill 掉那个事务，它只会按时抛错，剩下的得你自己兜底。
容易被忽略的关键点
最常被跳过的其实是隔离级别与锁粒度的联动影响。比如在 REPEATABLE READ 下，UPDATE ... WHERE non_unique_column = ? 会触发临键锁（Next-Key Lock），锁住整个范围，而不仅仅是匹配行；换成 READ COMMITTED，间隙锁会被禁用，锁范围大幅缩小，锁冲突概率直降。这不是调个超时参数能绕开的问题。
另一个隐形坑是 autocommit 状态：如果应用层关闭了 autocommit 但忘了 commit/rollback，哪怕只执行了一条 SELECT ... FOR UPDATE，这个事务就会一直持有锁，直到连接断开或超时。这类事务在 PROCESSLIST 里显示为 Sleep，但在 INNODB_TRX 里状态仍是 RUNNING，必须靠 trx_started 时间戳识别。
