应先定位阻塞源而非调参：1. 查innodb_trx中trx_state='lock wait'的事务；2. 关联innodb_lock_waits找blocking_trx_id；3. 通过processlist查该线程执行状态，确认是否未提交或卡在外部调用；php层须避免事务内调外部服务、确保where走索引、实现退避重试。
锁等待超时不是 PHP 代码写错了，而是 MySQL 的 innodb_lock_wait_timeout 被触发了——事务在等一把别人没释放的锁，等太久就被强制中断。直接改超时时间治标不治本，得先定位谁在卡、为什么卡。
查哪个事务在阻塞别人
别只看 PHP 报错日志，进 MySQL 执行这三步：
-
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TRX_STATE = 'LOCK WAIT'—— 找出正在等待的事务，记下它的TRX_ID和TRX_MYSQL_THREAD_ID -
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS—— 用上一步的TRX_ID关联BLOCKING_TRX_ID，找到“持锁不放”的那个事务 ID -
SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE ID = ?—— 把上一步的BLOCKING_TRX_ID对应的线程 ID 填进去，看它卡在哪条 SQL 上，是不是忘了COMMIT或者卡在 HTTP 请求里
PHP 层最该改的三件事
很多锁等待问题，根源在 PHP 事务包裹太宽、条件没走索引、重试逻辑失控：
- 事务里禁止调外部服务：
curl_exec()、file_get_contents()、日志写入这些操作必须挪到DB::transaction()外面，否则锁白白挂着几十秒 - UPDATE/DELETE 的
WHERE条件必须命中索引：用EXPLAIN看type是range或ref，不是ALL；没索引就加，别指望优化器自动选对 - 捕获错误后带退避重试：
1205（死锁）和1206（锁超时）要单独 catch，用usleep(10000)→usleep(30000)→usleep(100000)这类指数退避，别用固定 100ms 疯狂重试
MySQL 配置和索引补漏点
线上环境容易忽略两个低级但致命的问题：
-
innodb_lock_wait_timeout别乱调大：默认 50 秒，线上建议设为30，配合监控告警；设成 300 秒只会让失败请求拖更久，掩盖真实瓶颈 - 自增主键 + 唯一索引并发插入时，
INSERT ... ON DUPLICATE KEY UPDATE或REPLACE INTO容易因间隙锁冲突引发等待——确认唯一索引字段建全了，且业务能接受乐观锁替代方案（比如加version字段） - 本地开发用 phpEnv 时，务必检查
my.ini是否开了innodb_print_all_deadlocks = ON，否则死锁日志只留最后一次，根本没法回溯
真正难处理的不是单次超时，而是那些“看起来正常但偶尔卡住”的事务——它们往往混着文件读写、没关的 PDO 连接、或跨表更新顺序不一致。这类问题不会报错，但会悄悄拖慢整个数据库响应曲线。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
