Lock wait timeout exceeded是MySQL层锁等待超时，需检查phpEnv实际运行的MySQL实例、确认innodb_status_output开启、验证事务真实存在性、排查配置覆盖及日志关闭问题。
这不是 phpEnv 的问题，也不是 PHP 环境配置能直接修好的——Lock wait timeout exceeded 是 MySQL 层面的锁等待超时，phpEnv 只是套了个本地开发环境壳子，它不干预事务生命周期、不改 InnoDB 锁行为、也不自动帮你提交或回滚。
查不到长事务？先确认 phpEnv 用的是不是你以为的那个 MySQL
phpEnv 默认可能启多个 MySQL 实例（比如 5.7 和 8.0 并存），而你连的未必是正在报错的那个：
- 执行
ps aux | grep mysql，看实际运行的 mysqld 进程绑定的是哪个port和socket - 进 PHP 脚本里打一行
var_dump(PDO::ATTR_CONNECTION_STATUS);或用mysqli_get_client_info()确认连接的真实服务端版本 - 别直接连
localhost——改用127.0.0.1:3307显式指定端口，避免 socket 文件路径混淆
INNODB_TRX 查不到记录？检查 phpEnv 的 MySQL 是否开了 innodb_status_output
phpEnv 封装的 MySQL 配置常默认关闭性能诊断开关，导致 SHOW ENGINE INNODB STATUS 返回空或不完整：
- 进 phpEnv 对应的
my.cnf（通常在~/.phpenv/versions/*/etc/my.cnf），确认有这行：innodb_status_output = ON - 重启该实例：
phpenv mysql:restart 8.0（按你实际版本号） - 再执行
SELECT * FROM information_schema.INNODB_TRX;，如果仍为空，说明当前没活跃事务；但若报错Table 'information_schema.INNODB_TRX' doesn't exist，则是权限不足或 MySQL 版本太低（
重试逻辑写了但没生效？PHP 连接未设 PDO::ATTR_EMULATE_PREPARES = false
phpEnv 下某些旧版 PHP + MySQL 组合默认开启预处理模拟，会导致事务上下文丢失，ROLLBACK 不触发，锁一直挂着：
立即学习“PHP免费学习笔记（深入）”；
- 建 PDO 时必须显式关闭模拟：
new PDO($dsn, $user, $pass, [PDO::ATTR_EMULATE_PREPARES => false]) - 否则即使代码里写了
$pdo->beginTransaction()→catch→$pdo->rollback()，MySQL 实际收到的仍是多条独立语句，没有真正事务边界 - 验证方式：在事务中执行
SELECT CONNECTION_ID()，再开另一个终端连同一实例，查SHOW PROCESSLIST，看是否显示Command=Sleep且Time持续增长
调大 innodb_lock_wait_timeout 反而更卡？phpEnv 的 MySQL 配置加载顺序陷阱
phpEnv 启动 MySQL 时，会合并系统级、实例级、命令行三处配置，innodb_lock_wait_timeout 很容易被覆盖：
- 先查生效值：
mysql -u root -e "SELECT @@innodb_lock_wait_timeout;" - 常见冲突点：phpEnv 自带的
my.cnf设了50，但你在~/.my.cnf里又写了innodb_lock_wait_timeout = 10，后者优先级更高 - 临时调试可用会话级设置：
SET SESSION innodb_lock_wait_timeout = 5;，立刻暴露隐藏长事务，比全局改更安全
最易被忽略的一点：phpEnv 本地环境常把所有日志关掉，slow_query_log=OFF、general_log=OFF 全默认，结果你根本看不到哪条 UPDATE 卡了 3 分钟——记得手动打开 general_log = ON 并指定 general_log_file=/tmp/mysql-general.log，否则排查全靠猜。
