MySQL的UPDATE在REPEATABLE READ下不基于MVCC快照读更新，而是先加X锁再读最新数据；无索引时全表扫描并逐行加记录锁；仅READ COMMITTED+唯一索引等值查询可规避间隙锁；autocommit=1时每条UPDATE均为独立事务，需显式BEGIN才能保证跨语句一致性。
MySQL 的 UPDATE 默认在 REPEATABLE READ 隔离级别下执行，但它不靠 MVCC 快照读更新——而是先加锁、再用最新数据判断。想靠隔离级别“自动防错”，大概率会踩坑。
UPDATE 为什么不是读快照再更新？
很多人以为 REPEATABLE READ 下 UPDATE 会基于事务开始时的快照执行，结果发现并发更新仍冲突或覆盖。真相是：UPDATE 会先对 WHERE 匹配的行加 X 锁（记录锁或间隙锁），然后**直接读取当前最新版本**做条件判断和修改。MVCC 快照只用于 SELECT，不参与写逻辑。
- 常见错误现象：
Deadlock found when trying to get lock；两个事务交替更新同一行，后提交的覆盖前提交的值（尤其 WHERE 是范围条件时） - 根本原因：误把读一致性当成写一致性，忽略了写操作的加锁+最新读行为
- 验证方式：开启
innodb_status或用SHOW ENGINE INNODB STATUS查看锁等待链
WHERE 没走索引时，UPDATE 实际锁了什么？
没索引 → InnoDB 无法定位目标行 → 全表扫描 + 对每行加记录锁 → 效果等同于锁住整个聚簇索引。这不是“锁表”，但其他事务对任意行的 UPDATE、DELETE 或相同 WHERE 条件都会被阻塞。
- 使用场景：线上误写
UPDATE orders SET status = 'done' WHERE status = 'pending'，而status无索引，整张订单表卡住数秒 - 快速排查：
EXPLAIN看type是否为ALL，key是否为NULL - 注意：即使有索引，若条件含前导模糊匹配（如
name LIKE '%alice'），也可能退化为全扫
怎么真正避开间隙锁（Gap Lock）？
间隙锁是 REPEATABLE READ 下防幻读的关键，但也正是死锁高发源。唯一能完全规避它的组合是：READ COMMITTED + WHERE 匹配**唯一索引**且为**等值查询**（如 WHERE id = 100）。
- 范围查询（
WHERE id > 100）或非唯一索引（WHERE name = 'Alice'）仍会锁间隙 - 性能权衡：关间隙锁可降死锁概率，但允许幻读——资金类业务通常不能接受
- 替代方案：
INSERT ... ON DUPLICATE KEY UPDATE在唯一键冲突时只锁冲突行，不锁间隙，比先SELECT再UPDATE更安全
事务必须显式开启，否则根本没隔离可言
MySQL 默认 autocommit = 1，每条 UPDATE 都是独立事务，谈不上跨语句的一致性保障。所谓“在事务里更新”，90% 的 case 其实只是幻觉。
- 常见错误：Python 中只设
conn.isolation_level = None，没调conn.execute("BEGIN")；Node.js 用pool.query()直接发UPDATE，没走client.query("BEGIN") - 关键点：所有相关 SQL 必须在**同一个数据库连接**内完成；跨连接、跨 HTTP 请求的操作，不可能共用一个事务上下文
- 出错后
ROLLBACK不会自动触发——必须手动捕获异常并执行，否则连接可能带着未结束事务回到连接池，引发后续锁表或状态混乱
最常被忽略的其实是锁的粒度与顺序：哪怕隔离级别调得再高，如果多行 UPDATE 没按固定顺序（比如始终按主键升序）执行，死锁就几乎不可避免。这不是配置问题，是代码逻辑问题。
