应先定位锁等待根源而非调大innodb_lock_wait_timeout：查performance_schema.data_locks或SHOW ENGINE INNODB STATUS，结合INNODB_TRX与threads定位阻塞事务和SQL，再优化索引、避免隐式长事务、精简外键、改用乐观锁等。
迁移后出现 Lock wait timeout exceeded 错误怎么办
这是典型的共享锁（S-lock）或排他锁（X-lock）在长事务或未提交事务阻塞下触发的超时。MySQL 迁移后常因应用未适配新环境（比如连接池配置、事务边界变化），导致事务堆积，innodb_lock_wait_timeout 默认 50 秒很快被耗尽。
别急着调大超时值——它只是掩盖问题，不是解决锁争用。先确认是否真有锁等待：
- 执行
SELECT * FROM performance_schema.data_locks;（MySQL 8.0+）或SHOW ENGINE INNODB STATUS\G查看当前锁信息 - 检查
information_schema.INNODB_TRX中TRX_STATE = 'LOCK WAIT'的事务及其TRX_MYSQL_THREAD_ID - 关联
performance_schema.threads找出对应 SQL 和应用线程
innodb_lock_wait_timeout 调整的适用场景与风险
该参数只控制单次锁等待的最长容忍时间，**不影响锁本身是否产生，也不影响事务隔离级别或锁粒度**。它只在“等不到锁”时抛出错误，让应用有机会重试或降级。
调整前需明确：是偶发性长查询阻塞（可临时加大），还是高频短事务反复冲突（说明业务逻辑或索引有问题）？
- 全局修改（重启生效）：
SET GLOBAL innodb_lock_wait_timeout = 120;（不推荐线上随意改） - 会话级修改（当前连接有效）：
SET SESSION innodb_lock_wait_timeout = 60;，适合已知会长时间持有锁的维护脚本 - 应用层更稳妥：在执行关键 DML 前显式设置，如 JDBC 中用
connection.createStatement().execute("SET SESSION innodb_lock_wait_timeout = 30") - 注意：该值不能设为 0（MySQL 5.7+ 不允许），最小值为 1；设得过大（如 300）会导致问题排查延迟，掩盖慢 SQL 或未提交事务
真正缓解共享锁冲突的实操手段
共享锁（S-lock）常见于 SELECT ... LOCK IN SHARE MODE、外键约束校验、或唯一索引重复值插入前的判断。迁移后冲突变多，往往因为数据分布/统计信息变化，导致原本走索引的查询开始全表扫描加锁，或二级索引覆盖不足引发聚簇索引回表加锁。
- 检查并优化相关查询是否走了预期索引：
EXPLAIN FORMAT=JSON看key和rows_examined - 避免在高并发路径上使用
SELECT ... LOCK IN SHARE MODE，改用应用层缓存或乐观锁（如version字段 +WHERE version = ?） - 确认外键约束是否必要——迁移后若子表数据量激增，外键的 S-lock 检查开销会明显上升；非强一致性场景可考虑去掉外键，由应用保证
- 确保
autocommit = 1，防止隐式事务长期挂起；检查 ORM 是否开启了不必要的事务包装（如 Spring 的@Transactional作用域过大）
为什么只调 innodb_lock_wait_timeout 很难根治
这个参数就像给堵车路口加个倒计时喇叭——提醒你“再等 50 秒就放弃”，但喇叭响了十次，你该修的是红绿灯配时或拓宽车道，而不是换更大音量的喇叭。
真实瓶颈往往藏在：未提交事务卡住锁、缺失索引导致锁范围扩大、批量更新未分页、或应用重试逻辑把失败请求反复推回队列。这些都不会因超时值从 50 改成 120 而消失，只会让故障暴露得更晚、更难定位。
