事务中 UPDATE 多行易死锁，因 InnoDB 行锁顺序依赖索引扫描路径；若两事务以不同顺序更新同一主键集（如 A 先 5 后 2、B 先 2 后 5），将形成循环等待。
为什么 事务里 update 多行容易触发死锁
MySQL 的 InnoDB 在执行 UPDATE 时默认加的是行级锁，但锁的获取顺序和索引扫描路径密切相关。如果两个事务以不同顺序更新同一组主键（比如事务 A 先改 id=5 再改 id=2，事务 B 反过来），就可能形成循环等待 —— 这就是典型的死锁根源。
更隐蔽的是：即使 SQL 看起来一样，只要执行计划不同（例如一个走主键索引、另一个走二级索引覆盖扫描），实际加锁的行和顺序也可能不一致。
- 确保所有批量
UPDATE按主键升序 排列 后再执行（应用层排序或用ORDER BY PRIMARY KEY） - 避免在事务中混合使用
SELECT …… FOR UPDATE和UPDATE，尤其当SELECT走的是非唯一索引时，可能锁住间隙（Gap Lock） - 用
SHOW ENGINE INNODB STATUSG查看最近死锁详情，重点关注TRANSACTION块里的lock_mode和lock_trx_id
唯一索引 vs 普通索引对死锁的影响
更新条件命中唯一索引（如主键或 UNIQUE 键）时，InnoDB 能精确定位单行并只加记录锁；而命中普通索引时，由于无法保证唯一性，InnoDB 会额外加间隙锁（Gap Lock），锁定索引区间，大幅增加锁冲突概率。
比如表 t 有普通索引 idx_status，执行 UPDATE t SET name='x' WHERE status=1，可能锁住所有 status=1 的行及其之间的空隙 —— 即使另一事务只更新 status=2，若它们物理相邻，也可能被波及。
- 高频更新字段尽量建
UNIQUE索引（哪怕业务上不强制唯一，也可配合应用逻辑保证） - 避免在
WHERE条件中使用函数或类型 隐式转换（如WHERE DATE(create_time) = '2024-01-01'），这会让索引失效，退化为全表扫描 + 全表加锁 - 用
EXPLAIN FORMAT=JSON确认执行计划是否真的用了预期索引，并观察key_locks字段
如何用 SELECT FOR UPDATE 安全地预占资源
SELECT …… FOR UPDATE 不是“保险丝”，它本身就会加锁，且锁的范围由查询条件和索引决定。常见误区是认为“先查再更”比直接 UPDATE 更安全，实际上如果 SELECT 锁得过宽，反而更容易引发死锁。
SELECT id FROM orders WHERE user_id = 123 AND status = 'pending' ORDER BY id LIMIT 1 FOR UPDATE;这段语句看似只取一行，但如果 user_id + status 没有联合索引，MySQL 可能先扫全表匹配 user_id，再过滤 status，导致锁住大量无关行。
- 必须为
SELECT FOR UPDATE的WHERE条件建立覆盖索引，且列顺序要匹配查询谓词（如(user_id, status, id)） - 禁止在事务中执行无
WHERE条件或仅用LIKE '%xxx'的SELECT FOR UPDATE，这等于给整张表上锁 - 如果只是防止重复插入，优先用
INSERT …… ON DUPLICATE KEY UPDATE，它在唯一键冲突时自动转为更新，无需显式加锁
长事务和 autocommit=0 是死锁温床
事务越长，持 有锁 的时间就越久，其他事务等待的概率指数上升。尤其当 autocommit=0 且忘记 COMMIT 或 ROLLBACK，锁会一直挂着，后续任何相关操作都可能被堵死。
线上曾见过一个后台任务开启事务后调用外部 HTTP 接口，接口超时 30 秒，期间所有同用户订单更新全部阻塞 —— 根本不是 SQL 写得不好，而是事务边界失控。
- 所有应用代码中显式开启事务的地方，必须配对
try/finally或使用上下文管理器确保COMMIT/ROLLBACK - 数据库连接池配置
wait_timeout和interactive_timeout（建议 ≤ 300 秒），让空闲长连接自动断开，释放锁 - 监控
INFORMATION_SCHEMA.INNODB_TRX表，定期告警trx_state = 'RUNNING'且trx_started超过 60 秒的事务
