优先用set session配合连接池初始化sql，再优化索引与事务；查当前值执行show variables like 'innodb_lock_wait_timeout'，注意其可能继承自全局或连接池初始化时刻。
直接说结论：别全局硬调，优先用会话级 SET SESSION + 应用连接池初始化 SQL，再配合索引和事务拆分——否则参数再准也白搭。
怎么查当前生效值？别信配置文件，看运行时
执行 SHOW VARIABLES LIKE 'innodb_lock_wait_timeout' 拿到的是当前会话值，但它可能来自全局默认、连接池初始化时读取的配置，或你之前手动 SET SESSION 过。尤其用 HikariCP、Druid 或 pymysql pool 时，这个值大概率是连接建立那一刻从全局继承来的，不是你临时改的。
- 想确认某条 SQL 实际受哪个值约束？在它前面加
SELECT @@innodb_lock_wait_timeout; - 查所有活跃连接的真实值：
SELECT THREAD_ID, VARIABLE_VALUE FROM performance_schema.variables_by_thread WHERE VARIABLE_NAME = 'innodb_lock_wait_timeout'; - 注意：
SET GLOBAL不影响已存在的连接，包括连接池里正在复用的连接——它们仍用旧值
设成多少秒才算合理？看业务类型，不看“建议值”
默认 50 秒对 Web 接口太危险：框架超时常设 5–10 秒，数据库还在等锁，线程就卡死了。但也不能无脑压小，否则正常争抢也频繁失败。
- 订单/支付类 OLTP：15 秒 —— 足够覆盖网络抖动和轻量锁冲突，又不至于拖垮接口
- 已接入重试 + 幂等的服务：20–25 秒 —— 给重试留出缓冲，避免重试还没发起就被杀掉
- 秒杀库存扣减（逻辑极简、竞争激烈）：5–8 秒 —— 快进快出，失败即重试，不等
- 报表或批量导入：60–300 秒 —— 防止中途被杀导致数据不一致；但必须确保事务内没混 HTTP 调用或日志写入
- 绝对不要设为 0（无限等待）或 >60 秒 —— 等于主动放弃故障隔离
怎么改才真正落地？三类方式风险完全不同
改参数容易，让应用真正按预期行为难。关键在“谁受影响”和“何时生效”。
-
SET SESSION innodb_lock_wait_timeout = 15：只改当前连接，适合放进连接池的connection-init-sql（如 HikariCP 的connection-init-sql配置），最安全可控 -
SET GLOBAL innodb_lock_wait_timeout = 15：需 SUPER 权限，新连接立即生效，但旧连接（含连接池中复用的）完全不受影响；线上灰度可用，但得配合连接池滚动重启 - 写进
/etc/my.cnf的[mysqld]段：innodb_lock_wait_timeout = 15：永久生效，但 Linux 下必须重启 MySQL；K8s/Docker 环境务必确认配置已挂载进容器，别只改了本地文件
为什么设了还是报 Lock wait timeout exceeded？参数根本没机会生效
这个错误出现，90% 的情况说明你没解决根因——innodb_lock_wait_timeout 只管“等锁”，不管“锁太久”或“锁范围太大”。
- UPDATE 语句没走索引 → 全表扫描，持锁几十秒，别人等它时超时，但它自己不会被中断
- 事务里调了外部 HTTP 接口 → 锁持有时间 = SQL 执行 + 网络耗时 + 业务逻辑，参数只约束前者
- 子查询或 JOIN 没命中索引 → 执行计划出现
type: ALL或rows_examined极高，立刻补索引 - 死锁报错也是
ERROR 1205，但它是 InnoDB 秒级检测并回滚，跟这个参数无关；真要区分，看SHOW ENGINE INNODB STATUS\G里的deadlock关键字
最容易被忽略的点：参数再细，也救不了没索引的查询、没 commit 的事务、或者存储过程里一个裸写的 SLEEP(60)——它们都不触发行锁等待，innodb_lock_wait_timeout 完全不生效。
