为什么事务里 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 STATUS\G查看最近死锁详情，重点关注
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 秒的事务 死锁无法完全消除，但大多数生产环境死锁都源于事务粒度失控、索引设计失当或执行路径不可控 —— 把锁的范围和生命周期看得比 SQL 性能还重，问题就解决了一大半。
