应立即执行SHOW ENGINE INNODB STATUS\G，重点查看LATEST DETECTED DEADLOCK区块中的两个事务ID、各自SQL语句、持有锁（HOLDS THE LOCKS）与等待锁（WAITING FOR THIS LOCK）、索引使用及主键值，结合锁模式与操作顺序定位死锁根因。
phpEnv 是本地开发环境套件，底层 MySQL 默认用 InnoDB 引擎、RR 隔离级别，死锁不是配置错误，而是并发逻辑和 SQL 写法触发的必然现象。直接杀进程或调大 innodb_lock_wait_timeout 只是掩盖问题，真正要改的是事务结构和索引设计。
show engine innodb status 看到的死锁信息怎么读
这是排查唯一可信的入口，SHOW ENGINE INNODB STATUS 输出里关键看三块：
- *** (1) TRANSACTION: —— 被回滚的那个事务，注意它的
query和lock_structs - *** (2) TRANSACTION: —— 活着的那个事务，它持有的锁（
LOCK WAIT行说明它在等什么） - WEIGHT: 数值小的事务被选为牺牲者，InnoDB 自动决定，不以执行先后为准
重点对照两者的 SQL：是否都用了范围条件（比如 WHERE id > 10 AND id ）、是否走了相同索引但顺序相反、是否一个走主键一个走二级索引。这些都会导致 <code>Next-Key Lock 范围重叠或错位。
PHP 事务中 beginTransaction() 后没提交就挂了怎么办
phpEnv 没有自动清理机制，断开连接或脚本异常退出时，INNODB_TRX 里残留的事务会继续持锁，后续请求可能直接卡住或触发新死锁。
立即学习“PHP免费学习笔记（深入）”；
- 先查残留：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60（找运行超 1 分钟的） - 再确认是否真卡住：
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS，有结果说明正堵着 - 别急着
KILL，先看它在跑什么：SELECT trx_mysql_thread_id, trx_query FROM information_schema.INNODB_TRX WHERE trx_id = 'xxx' - 确认无业务影响再
KILL <code>thread_id，否则可能中断正在写的订单或库存扣减
为什么加了索引还是死锁？
常见错觉：只要 EXPLAIN 显示 type=range 就安全。实际在 RR 级别下，以下情况仍会扩大锁范围：
- WHERE 条件含函数或隐式类型转换（如
WHERE user_id = '123'但字段是INT）→ 索引失效 → 全表扫描 + 行锁升级为表级意向锁 - 联合索引只用左前缀（如索引是
(a,b,c)，但查询用WHERE b = 1）→ 无法走索引 → 间隙锁覆盖整段范围 - UPDATE 没带 WHERE，或 WHERE 匹配到 0 行 → InnoDB 仍会对“可能插入的位置”加间隙锁（防幻读）
验证方法：在 phpEnv 的 MySQL 命令行里执行 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS，看 LOCK_TRX_ID 对应的锁类型是不是大量 RECORD + GAP 组合。
PHP 代码里怎么降低死锁概率
不是靠 try-catch 重试就能解决的。核心是让事务变短、锁变窄、顺序变一致：
- 把网络请求、文件读写、循环计算全挪到
beginTransaction()之前，事务内只做 DB 操作 - 多表更新必须固定顺序：比如所有涉及
orders和inventory的事务，统一先锁orders再锁inventory - 避免
SELECT ... FOR UPDATE查完再 UPDATE，改用UPDATE ... WHERE一条语句原子完成 - 批量操作拆成单条：不要
UPDATE t SET x=1 WHERE id IN (1,2,3,4,5)，改用循环 + 单条UPDATE，虽然慢一点，但锁范围可控
最易被忽略的一点：phpEnv 默认没开慢日志，但死锁往往伴随长事务。建议在 my.ini 里加上 slow_query_log = 1 和 long_query_time = 1，跑几天后用 mysqldumpslow 扫一遍，比盯着报错更早发现问题。
