innodb_lock_wait_timeout是“等锁超时”而非“锁超时”，仅控制UPDATE/DELETE/SELECT FOR UPDATE等待行锁的最长时间（默认50秒），超时报ERROR 1205，需结合SHOW ENGINE INNODB STATUS区分死锁；它不控制事务总耗时或已持锁释放，设5秒仅表示最多等5秒，非5秒自动提交；误调该值无法解决长事务未提交、缺失索引致锁升级等根本问题。
innodb_lock_wait_timeout 不是“锁超时”，而是“等锁超时”
它只控制事务在执行 UPDATE、DELETE 或 SELECT FOR UPDATE 时，**等待别人释放行锁**的最长时间。一旦超时，MySQL 就回滚当前语句并报错 ERROR 1205 (40001): Lock wait timeout exceeded（注意：这个错误码和死锁一样，但原因不同，得看 SHOW ENGINE INNODB STATUS\G 才能区分）。
它不控制事务总耗时，也不影响已持有的锁；设成 5 秒，不代表事务 5 秒后自动提交或回滚——只是“等锁”最多忍 5 秒。
- 误判常见于看到报错就调大该值，结果发现还是超时：真正卡住的是一个没提交的长事务，不是“等太久”，而是“对方一直不放”
- 应用层配了
socketTimeout=3000（如 JDBC），客户端 3 秒就断了，MySQL 根本没机会抛出这个错误，你看到的可能是连接异常，而非锁超时 -
UPDATE user SET status=1 WHERE name='xxx'没走索引？那就可能全表扫描+间隙锁，锁范围远超单行，innodb_lock_wait_timeout压根不是瓶颈
怎么改才真生效，而不是“以为改了”
动态设置分三层，作用域和持久性完全不同：
- 会话级（调试单条 SQL 最安全）：
SET SESSION innodb_lock_wait_timeout = 10，仅当前连接有效，退出即失效 - 全局级（只对新连接生效）：
SET GLOBAL innodb_lock_wait_timeout = 15，已连上的旧连接仍用原值；线上服务 reload 配置不会触发重连，所以连接池里大量旧连接还在用默认 50 秒 - 永久生效（必须重启或 reload）：写进
/etc/my.cnf的[mysqld]段，例如：[mysqld]\ninnodb_lock_wait_timeout = 15
，然后执行sudo systemctl restart mysql或mysqladmin reload（部分版本支持）
特别注意：HikariCP 等连接池需配合 maxLifetime 主动淘汰旧连接，否则新参数永远进不了业务流量。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
OLTP 场景下设多少算合理
没有标准值，关键看三件事是否对齐：数据库参数、应用层超时、业务容忍度。
- 前端 Nginx 有
proxy_read_timeout=60？那 MySQL 设 300 秒毫无意义，用户早看到 504 了 - 支付类强一致性操作：建议 5 秒——失败要快，留给幂等重试或降级的时间窗更宽
- 普通订单/评论提交：15 秒较稳妥——覆盖网络抖动、临时 IO 延迟，又不至于让线程池被占满
- 无重试机制的应用：别超过 15 秒，否则失败后用户只能刷新，体验崩坏
- 绝对不要设为 0：官方明确不推荐，等于无限等待，极易引发连接堆积甚至雪崩
比调参更重要的三件事
90% 的人一上来就改参数，却跳过真正要盯的根因：
- 谁在持锁？跑这句查运行超 60 秒的事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - TRX_STARTED) > 60，再顺藤摸瓜找到对应应用代码 - 锁为什么这么大？对报错 SQL 跑
EXPLAIN，确认type不是ALL；缺失索引导致全表扫描，锁升级是常态 - 事务里有没有混非 DB 操作？比如 HTTP 调用、
Thread.sleep(5000)、文件读写——这些会让锁持有时间完全失控，参数再准也没用
参数只是痛感刻度盘，不是止血钳。锁超时暴露的是资源竞争，不是配置失误。
