SQL事务隔离依赖锁机制、MVCC和可见性规则协同实现，核心在于厘清读写主体、时机及数据版本判定；隔离级别仅定义可见性规则，不直接控制锁。
SQL事务隔离不是靠“设个级别就完事”，而是数据库在并发读写时，通过锁机制、多版本控制（MVCC）和可见性规则共同作用的结果。理解它，关键要拆清“谁在读、谁在写、什么时候读、数据版本怎么判定”这四条线。
隔离级别决定“可见性规则”，不直接控制锁
很多人以为设置 READ COMMITTED 就等于“不加锁”，其实不然——它只规定“只能看到已提交的数据”，但实现方式因引擎而异：
- InnoDB 默认用 MVCC：普通 SELECT 不加锁，靠 Read View 判断某行对当前事务是否可见；UPDATE/DELETE 仍会对目标行加行锁
- SQL Server 在 READ COMMITTED 下默认使用共享锁（锁读），读完即放，所以可能遇到不可重复读
- PostgreSQL 全面依赖 MVCC，连锁读都避免，靠快照隔离（SI）实现
真正影响性能瓶颈的，往往不是隔离级别本身，而是它背后触发的锁范围和持有时间。
脏读、不可重复读、幻读，本质是“读到了不该读的版本”
这三类现象不是孤立 bug，而是同一逻辑链条上的不同断裂点：
- 脏读：读到了其他事务未提交的中间态版本（比如事务A改了name但没提交，事务B读到了）→ 源于 Read View 生成太早或未校验提交状态
- 不可重复读：同一事务中两次读同一行，结果不同（比如事务A第一次读 age=25，事务B提交更新为26，A再读变成26）→ Read View 复用失败，第二次读用了新快照
- 幻读：同一事务中两次执行相同范围查询，返回行数不同（比如事务A查 status=0 的订单有3条，事务B插入1条并提交，A再查变4条）→ 范围条件未被锁住，或新插入行的版本在当前 Read View 中“意外可见”
注意：幻读在 InnoDB 的可重复读（RR）下仍可能发生（如 insert 新记录），只是通过间隙锁（Gap Lock）+ Next-Key Lock 抑制了“索引区间内”的幻读，不是彻底消除。
锁不是万能解，MVCC 也不是银弹
选对机制比硬加锁更重要：
- 高频读+低频写场景，优先靠 MVCC 降低冲突，避免读阻塞写
- 强一致性要求（如库存扣减），单行操作用 SELECT ... FOR UPDATE 显式加行锁，比依赖隔离级别更可控
- 范围更新（如 UPDATE orders SET status=1 WHERE status=0）必须意识到：RR 级别下 InnoDB 会自动升级为 Next-Key Lock，可能锁住整个区间，引发死锁或长事务阻塞
- 想彻底规避幻读？应用层加唯一约束 + 重试，或升级到 PostgreSQL 的可序列化（Serializable）快照隔离（SSI），它用冲突检测代替锁
调试隔离问题，盯住三个真实信号
别只看文档定义，动手时看这些：
- 查 information_schema.INNODB_TRX：看当前有哪些事务在跑、状态、运行时间、关联的锁
- 用 SHOW ENGINE INNODB STATUS\G：重点看 TRANSACTIONS 部分的 last SQL、lock wait、以及死锁日志里的“WAITING FOR THIS LOCK TO BE GRANTED”
- 开启慢查询+通用日志（general_log），结合时间戳对齐事务起点，还原并发时序
很多“隔离失效”实际是应用没正确开启事务（比如用 auto-commit 模式执行多条语句）、或 ORM 自动提交打断了逻辑单元。
基本上就这些。事务隔离不是配置开关，而是读写逻辑、存储引擎特性、SQL 写法三者咬合的结果。理清版本可见性这条主线，再叠加上锁行为和时序影响，系统性掌握就水到渠成。
