innodb_lock_wait_timeout 是事务等待行锁的最长时间，超时仅中断当前语句而不回滚事务；调大它不能解决锁等待问题，反而加剧阻塞；应优先优化索引、避免长事务，并在应用层捕获错误后主动回滚。
innodb_lock_wait_timeout 是什么，改它真能解决锁等待问题？
innodb_lock_wait_timeout 控制的是事务在等待行锁（如 UPDATE、DELETE 或带 FOR UPDATE 的 SELECT）时，最多等多久就报错 Lock wait timeout exceeded。它不控制死锁检测，也不影响事务是否自动回滚——超时后 MySQL 会主动中断当前语句并返回错误，但**事务本身不会自动回滚**，后续语句仍可执行，除非显式 ROLLBACK 或连接断开。
常见误操作：把 innodb_lock_wait_timeout 调到 300 秒以为“就能等更久”，结果只是让阻塞持续更久，反而加剧连接堆积和锁扩散。实际应优先排查为何锁等待频繁发生（如缺失索引、长事务、未加 WHERE 条件的 UPDATE），而非调大超时值。
- 默认值是
50秒，线上建议保持10–30秒之间，便于快速暴露问题 - 可在会话级临时调整：
SET SESSION innodb_lock_wait_timeout = 15; - 全局修改需重启或用
SET GLOBAL（仅对新连接生效） - 注意：该参数对
LOCK TABLES（表级锁）无效，只作用于 InnoDB 行锁等待
MySQL 会不会自动回滚事务？靠什么触发？
MySQL **不会因为锁等待超时而自动回滚整个事务**。超时只导致当前被阻塞的那条语句失败，START TRANSACTION 后的其他已执行语句仍保留在事务中，SELECT 结果、已更新的行都还处于未提交状态。
真正触发自动回滚的场景极少，只有两种明确情况：
- 客户端连接异常断开（如网络中断、应用进程崩溃），MySQL 检测到连接丢失后会回滚该连接上未提交的事务
- 启用了
autocommit = 0但执行了会导致隐式提交的语句（如CREATE TABLE、ALTER TABLE、UNLOCK TABLES），此时 MySQL 会先提交当前事务再执行该语句；但这不是“自动回滚”，而是“强制提交”
所以别指望 MySQL 在超时后帮你兜底。必须由应用层捕获 Lock wait timeout exceeded 错误，并主动执行 ROLLBACK，否则可能造成数据不一致或后续语句意外提交。
如何在应用中安全处理锁等待超时？
核心原则：不依赖数据库自动恢复，而是把重试 + 回滚逻辑收归应用控制。尤其要注意事务边界和错误分类。
- 区分错误类型：MySQL 错误码
1205是死锁（Deadlock found），1206是锁等待超时（Lock wait timeout），两者应不同策略处理（死锁通常立即重试，超时需先分析是否真卡住） - 避免在事务中做耗时操作（如远程 HTTP 请求、文件读写），否则极易拉长锁持有时间
- 使用
SELECT ... FOR UPDATE NOWAIT（MySQL 8.0.1+）可跳过等待直接报错，比等超时更快暴露冲突 - 应用日志里务必记录完整上下文：SQL、事务开始时间、等待的锁资源（可通过
INFORMATION_SCHEMA.INNODB_TRX和INNODB_LOCK_WAITS查）
SELECT trx_id, trx_state, trx_started, trx_wait_started, trx_mysql_thread_id, trx_query FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_state = 'LOCK WAIT';
innodb_rollback_on_timeout 是否还有效？
这个参数在 MySQL 5.5 及更早版本中存在，设为 ON 时会让锁等待超时自动回滚整个事务。但从 MySQL 5.6 开始，该参数已被**移除且不再起作用**，文档明确标注为 “Deprecated and removed”。现在无论怎么设置 innodb_rollback_on_timeout，都不会改变行为。
如果你在配置文件里还看到它，或者应用日志里提示 “unknown variable”，说明你正在用 MySQL 5.6+ 却沿用了旧版配置。删掉这一行，把事务回滚责任交还给应用代码。
真正影响回滚行为的，只有三件事：应用是否调用 ROLLBACK、连接是否断开、是否执行了隐式提交语句。其它全是幻觉。
