合理值需按业务分级：金融类设5秒、普通web设15秒、离线任务设300秒；默认50秒在高并发下易放大故障，且必须配合innodb_rollback_on_timeout=on与索引优化等根治措施。
innodb_lock_wait_timeout设成多少才算合理
默认 50 秒在高并发写场景下不是“安全值”，而是故障放大器：一个事务卡住一行，上百个后续请求排队等锁，全部拖满 50 秒才失败，应用层表现为大面积超时或线程池耗尽。合理值取决于业务敏感度和重试能力，不是拍脑袋定的。
常见取值建议：
- 金融类强一致性操作（如支付扣款）：
innodb_lock_wait_timeout = 5—— 错误需秒级暴露，留给应用重试或降级的时间窗口更宽 - 普通 Web 业务（如订单创建、评论提交）：
innodb_lock_wait_timeout = 15—— 平衡用户体验与后台稳定性，多数正常 DML 应在毫秒级完成 - 离线任务或管理后台操作：
innodb_lock_wait_timeout = 300—— 避免因临时锁争用中断长流程，但需确保事务本身不长期持有锁
绝对不要设为 0（无限等待）或 300+（5 分钟以上），前者会让连接永远挂起，后者让问题延迟暴露，掩盖真实瓶颈。
全局设置 vs 会话设置，哪个更可控
全局设置（SET GLOBAL innodb_lock_wait_timeout = 15 或写入 my.cnf）对新建立的连接生效，但已存在的连接仍用旧值；会话设置（SET SESSION innodb_lock_wait_timeout = 15）只影响当前连接，适合调试或按业务模块差异化控制。
生产环境推荐组合策略：
- 基础值写进配置文件：
[mysqld]段落里设为15，作为兜底 - 关键业务连接池初始化时执行
SET SESSION innodb_lock_wait_timeout = 5，显式收紧 - 避免在 SQL 中动态 SET —— 容易被 ORM 自动连接复用绕过，且难以审计
SET GLOBAL 不需要重启 MySQL，但修改后不会立即影响所有连接，必须等旧连接断开重建才生效。别指望改完就立刻“全量切换”。
为什么调了 innodb_lock_wait_timeout 还是报 Lock wait timeout
这个参数只控制“等待锁”的时间，不解决“为什么等锁”。如果频繁报 Lock wait timeout exceeded，大概率不是超时设得太长，而是锁本身不该被等那么久。
典型真因：
- 缺失索引导致 UPDATE/DELETE 全表扫描，锁住几千行 → 用
EXPLAIN确认type是range或ref，key显示有效索引名 - WHERE 条件用了函数或隐式转换：
WHERE DATE(create_time) = '2024-01-01'或WHERE user_id = '123'（字段是 INT）→ 跳过索引，触发全表加锁 - 批量 IN 列表过大（如 5000 个 ID）→ 可能触发锁升级，考虑分批或改用临时表 JOIN
- 事务粒度太大，比如一个事务里混着 RPC 调用、文件读写、MySQL 更新 → 锁持有时间远超 SQL 执行本身
调低 innodb_lock_wait_timeout 只是让失败更快，不能替代索引优化和事务拆分。
必须配套开启 innodb_rollback_on_timeout
MySQL 8.0 默认 innodb_rollback_on_timeout = OFF，这意味着锁等待超时后，只是当前语句失败，事务仍处于活跃状态。后续语句若没检查错误就继续执行，极易造成部分更新、数据不一致。
生产环境务必设为 ON：
- 临时生效：
SET GLOBAL innodb_rollback_on_timeout = ON - 永久生效：写入
my.cnf的[mysqld]段落，并重启或确保配置持久化
开启后，Lock wait timeout exceeded 会触发整个事务回滚，但应用层必须捕获该错误并明确处理（如重试、告警、返回友好提示），不能依赖自动提交逻辑兜底。
最容易被忽略的一点：这个参数只对“锁等待超时”生效，对死锁（ERROR 1213 (HY000)）无效——死锁由 innodb_deadlock_detect 控制，且默认已开启。
