MySQL的MVCC是否无锁？我的相关理解是否正确？

你对更新步骤的理解修正与补充 #

你梳理的MySQL行更新步骤大体正确，但有几个细节可以补充：

• InnoDB的行更新操作本身是原子性的，不会出现“部分修改完成”的中间状态，要么全部修改成功，要么回滚到修改前的状态。
• 步骤4的redo log写入遵循**WAL（Write-Ahead Logging）**策略，先写redo log再刷磁盘，保证事务崩溃后可以恢复。

关于“无锁读会不会读到部分修改行”的问题 #

答案是不会，核心原因有两个：

1. 读视图的固定性：MVCC的快照读（普通SELECT操作）会在查询开始时创建一个读视图（Read View），这个视图一旦创建就固定了，它会记录当前系统中活跃的事务ID范围。后续更高事务ID的写操作，对于这个读视图来说是不可见的——读操作只会根据读视图的规则，从undo log版本链中找到符合可见性要求的旧版本数据来读取，不会去读正在修改的最新行。
2. 行更新的原子性：就算读操作在执行过程中，有写操作修改该行，写操作的整个过程是原子的，InnoDB会通过排他锁保证同一时间只有一个写操作修改该行，而且修改要么全部完成要么回滚，不存在“半修改”的行状态。

对MVCC“无锁”的澄清 #

线上资料说的MVCC“无锁”，特指快照读（普通SELECT）不需要加共享锁或排他锁，不会阻塞写操作，也不会被写操作阻塞。但如果是当前读（比如SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE，或者增删改操作），还是会加对应的锁，保证数据一致性。

内容的提问来源于stack exchange，提问作者kimasu ji