单条UPDATE语句本身不主动触发死锁，但它是死锁链关键一环；根本原因是锁获取顺序、索引路径与事务边界共同导致循环等待，InnoDB检测到即回滚任一事务。
单条 UPDATE 语句本身不会“主动”触发死锁，但它是死锁链中关键的一环——只要它在事务中执行、加了行锁、且与其他事务的锁请求形成循环等待，InnoDB 就会检测并报错 ERROR 1213 (40001): Deadlock found when trying to get lock。根本原因不是语句多复杂，而是锁的获取顺序 + 索引路径 + 事务边界共同作用的结果。
UPDATE语句加锁行为取决于执行计划
InnoDB 的行锁是“基于索引”的，UPDATE 加什么锁、锁多少行，完全由优化器选择的访问路径决定。一旦 WHERE 条件没走索引，后果很直接：
- 全表扫描 → 每一行都可能被加上
Record Lock（甚至升级为Next-Key Lock） - 锁范围爆炸，两个看似无关的
UPDATE可能因扫描重叠而互相阻塞 - 隐式类型转换（如
WHERE phone = 13800138000，而phone是VARCHAR）会让索引失效，等效于无索引 - 函数包裹字段（如
WHERE DATE(create_time) = '2026-11-04'）同样跳过索引，锁全表风险极高
事务隔离级别放大锁持有时间
在默认的 REPEATABLE READ 隔离级别下，UPDATE 获取的锁会一直持有着，直到事务结束（COMMIT 或 ROLLBACK）。这意味着：
- 一个简单的
UPDATE后如果还做了日志写入、RPC 调用、或人为加了SLEEP(2)，锁就挂在那里不动 - 另一个事务哪怕只查一行（
SELECT ... FOR UPDATE），只要涉及相同索引页，就可能卡住 -
READ COMMITTED下锁在语句结束后释放，死锁概率显著降低，但 MVCC 可见性逻辑更复杂，需权衡业务一致性
两条UPDATE如何构成死锁闭环
最典型的场景：两个事务以相反顺序更新同一组主键值。例如：
事务A：UPDATE t SET name='a' WHERE id=1; -- 先锁 id=1
UPDATE t SET name='b' WHERE id=2; -- 再锁 id=2
<p>事务B：UPDATE t SET name='x' WHERE id=2; -- 先锁 id=2
UPDATE t SET name='y' WHERE id=1; -- 再锁 id=1</p>
只要 A 拿着 id=1 等 id=2，B 拿着 id=2 等 id=1，InnoDB 在几毫秒内就能检测到循环等待并回滚其中一个。注意：这不是“谁先执行完”的问题，而是锁资源分配图出现了环。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
更隐蔽的是二级索引干扰——比如事务 A 用主键 id=5 更新，事务 B 用唯一索引 username='alice' 更新同一条记录，两者分别在聚簇索引和二级索引上加 X 锁，也可能触发死锁。
没有主键或唯一索引的表特别危险
当表缺失主键或唯一索引时，InnoDB 会自建隐藏的 row_id，但这个 ID 不参与索引排序，导致：
- WHERE 条件无法准确定位 → 实际执行变成全表扫描 + 所有行加锁
- 多个并发
UPDATE很容易锁住大量无关记录，大幅提高交叉冲突概率 - 死锁日志里看到的锁信息会异常冗长，难以快速定位热点行
线上表必须有主键，且高频 UPDATE 字段应建立合适索引——这不是规范建议，是避免单条语句引发雪崩的硬性底线。
