innodb_lock_wait_timeout默认50秒，仅影响UPDATE/DELETE等行锁等待，报错“Lock wait timeout exceeded”即由此触发；需通过修改phpEnv的my.ini文件[mysqld]段并重启MySQL服务来永久生效，临时SET GLOBAL需root权限且重启失效。
phpEnv 是 Windows 下的集成环境套件，它封装了 MySQL（通常是 MariaDB 或旧版 MySQL），但不提供图形化配置界面，所有 MySQL 参数修改必须直接操作配置文件或 SQL 命令——不能靠 phpEnv 面板点几下就生效。
怎么改 innodb_lock_wait_timeout（锁等待超时）
这个参数只影响事务内 DML 操作（如 UPDATE、DELETE）等待行锁的时间，默认 50 秒。报错 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 就是它触发的。
- 先确认当前值：
SELECT @@global.innodb_lock_wait_timeout; - 临时改（重启失效，仅对新连接生效）：
SET GLOBAL innodb_lock_wait_timeout = 120;（需 root 权限） - 永久改：打开 phpEnv 安装目录下的 MySQL 配置文件，路径通常是
C:\phpEnv\mysql\my.ini（不是my.cnf），在[mysqld]段下添加一行：innodb_lock_wait_timeout = 120 - 改完必须重启 phpEnv 的 MySQL 服务（通过 phpEnv 控制面板“重启 MySQL”或任务管理器杀掉
mysqld.exe进程再启）
为什么不能只改 session 级？
phpEnv 下 PHP 通常用短连接（mysql_connect 或 PDO 默认行为），每次请求新建连接，所以 session 级设置（SET innodb_lock_wait_timeout = 120）几乎没意义——刚设完就断了。更重要的是，很多 PHP 框架（如 Laravel）或连接池类库会复用连接，但 phpEnv 自带的 MySQL 没开连接池，session 级设置无法覆盖全局行为。
- session 级设置对已建立的连接有效，但 PHP 请求结束即释放连接，下次请求又是全新连接
- 如果你在 PHP 中执行
$pdo->exec("SET innodb_lock_wait_timeout = 120")，它只影响该次 PDO 连接生命周期，且必须在事务开始前执行 - 生产级稳定做法永远是改
my.ini+ 重启，避免依赖运行时 SQL 设置
PHP 层配合优化：别光调超时，要防锁争抢
单纯把 innodb_lock_wait_timeout 改到 300 秒，只是把报错延后，不解决根本问题——锁还在那里卡着。PHP 代码得主动减少锁持有时间：
立即学习“PHP免费学习笔记（深入）”；
- 事务里只做必要 DML，别混日志写入、HTTP 调用、文件操作等耗时逻辑
- 用
SELECT ... FOR UPDATE前，先用SELECT判断是否真要更新，避免无谓加锁 - 批量更新拆成小批次（比如每 100 行一个事务），降低单事务锁范围和时长
- 确保 WHERE 条件命中索引，否则
UPDATE可能升级为表锁或扫描大量行，加剧等待 - 在 PDO 连接后加保活检查：
if (!$pdo->getAttribute(PDO::ATTR_CONNECTION_STATUS)) { /* 重连 */ }，避免空闲连接被wait_timeout干掉后触发隐式重连+锁竞争
容易忽略的关联参数：wait_timeout 和 interactive_timeout
phpEnv 默认的 wait_timeout 往往是 28800（8 小时），看似够用，但实际 PHP-FPM 子进程可能长期复用 MySQL 连接，若中间网络抖动或防火墙中断，连接假死却未释放，后续事务就会卡在“等锁”状态，直到超时。这时你调 innodb_lock_wait_timeout 没用，得同步收紧：
- 在同一个
my.ini的[mysqld]段下，加上：wait_timeout = 300和interactive_timeout = 300 - 这会让空闲 5 分钟的连接自动断开，迫使 PHP 重建连接，避开假死连接引发的锁等待误判
- 注意：改完必须重启 MySQL，且 PHP 代码要有重连兜底（PDO 的
PDO::ATTR_ERRMODE设为EXCEPTION，捕获SQLSTATE[HY000] [2006] MySQL server has gone away后重试）
真正卡住的从来不是超时数字本身，而是事务里那条没走索引的 UPDATE、那个忘了提交的长事务、或者连接池里复用的脏连接——这些在 phpEnv 环境下更难监控，得靠 information_schema.innodb_trx 定期查，而不是盯着配置文件调数字。
