mysql死锁本质是多个事务以不同顺序争抢同一组行锁形成的循环等待；高发于innodb行锁+多语句事务，主因是加锁顺序不一致、间隙锁扩大、长事务及索引缺失。
死锁不是“用了事务就一定有”，而是多个事务以不同顺序争抢同一组行锁时卡住。ThinkPHP 的 Db::transaction() 默认不控制锁顺序和粒度，高并发更新同一批主键（比如扣库存、改订单状态）时，SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock 就会随机报出来。
为什么 MySQL 在 READ COMMITTED 下更不容易死锁
InnoDB 在 REPEATABLE READ（ThinkPHP 默认）下为防幻读启用间隙锁（gap lock），导致 UPDATE 实际锁住索引范围，而非仅目标行；而 READ COMMITTED 关闭间隙锁，只锁真正命中的记录，并支持半一致性读（semi-consistent read），UPDATE 时跳过已被其他事务修改但未提交的行，大幅缩小锁冲突面。
- 必须在连接建立时设置，不能在事务中用
SET SESSION TRANSACTION ISOLATION LEVEL ...临时改 —— 因为隔离级别在事务开始前就已确定 - 推荐在
database.php的'params'中加入：PDO::ATTR_INIT_COMMAND => "SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED" -
READ UNCOMMITTED不要碰：脏读会导致前端展示未提交的金额、状态等，业务不可接受
如何强制所有事务按同一顺序加锁
死锁本质是循环等待，只要所有事务对同一组记录加锁的顺序绝对一致，就不可能形成环。最简单可靠的做法是对待更新的主键或唯一键做升序排序后再执行操作。
- 不要写：
Db::table('order')->where('order_no', 'A')->update([...]); Db::table('order')->where('order_no', 'B')->update([...]);（顺序由参数传入顺序决定，不可控） - 应该先收集 ID 列表：
$ids = ['B', 'A']; sort($ids);，再遍历：foreach ($ids as $id) { Db::table('order')->where('order_no', $id)->update([...]); } - 批量更新也适用：用
WHERE order_no IN ('A','B')+ORDER BY order_no确保 InnoDB 内部扫描顺序固定（需确认该字段有索引）
哪些操作会让事务持锁时间变长、增加死锁概率
事务生命周期越长，锁被持有的时间就越久，其他事务撞上的机会就越大。很多死锁其实不是锁逻辑问题，而是事务里混进了不该有的东西。
- HTTP 请求（如调用支付回调、发短信）：网络 IO 可能长达数秒，期间锁一直挂着
- 文件读写（如生成日志、导出 Excel）：磁盘 IO 慢且不可控
- 大循环 DB 查询/更新：比如逐条处理 1000 条记录，应改用批量语句或分页+异步队列
- 没走索引的
SELECT ... FOR UPDATE：触发全表扫描，锁住成千上万行，别人一碰就等
捕获死锁后必须重试，但不能无脑重试
MySQL 检测到死锁后会自动回滚代价小的事务，并抛出 1213 错误。PHP 层必须捕获它并重试，否则用户看到的就是失败提示。
- 只重试
1213错误，其他异常（如连接断开、语法错误）直接抛出 - 最多重试 2–3 次，避免雪球效应；每次重试前加
usleep(10000 + rand(0, 5000))错开竞争时间 - 不要在重试逻辑里重新生成业务数据（如订单号、时间戳），否则可能造成重复下单或时间错乱
最易被忽略的一点：事务内任何一次查询如果没走索引，都可能把行锁升级为表锁或扩大为间隙锁范围——这比锁顺序错误更隐蔽，也更难排查。上线前务必用 EXPLAIN 过一遍所有带 FOR UPDATE 或 LOCK IN SHARE MODE 的语句。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
