READ COMMITTED 仍可能遇到不可重复读而非脏读，因其每条语句新建快照，导致同一事务内多次查询结果不一致；真正防脏读依赖行级读锁或MVCC一致性快照。
脏读为什么在READ COMMITTED里还可能遇到
READ COMMITTED 并不等于“完全安全”——它只保证读不到未提交的数据，但对同一行数据的多次读取之间，可能被其他事务更新并提交，导致第二次 SELECT 看到新值。这不是脏读（因为是已提交数据），但很多人误以为“已提交就稳了”，其实这是不可重复读。
真正防脏读，靠的是数据库在语句级别加行级读锁（如 PostgreSQL 的快照隔离），或 MVCC 机制中为每个事务分配一个一致性快照。MySQL InnoDB 在 READ COMMITTED 下每条语句都新建快照，所以两次 SELECT 可能看到不同结果；而 REPEATABLE READ 复用事务开始时的快照，这才挡住不可重复读。
- PostgreSQL 默认行为更接近 SQL 标准：
READ COMMITTED每次查询都取最新已提交快照，不防不可重复读 - MySQL InnoDB 的
REPEATABLE READ是基于 MVCC + 间隙锁（Gap Lock）实现的，它顺便也挡掉部分幻读，但这不是标准定义，而是实现副作用 - 别依赖“隔离级别名字听起来高级”，得看具体数据库怎么实现——比如 SQL Server 的
READ COMMITTED默认走锁，而开启READ_COMMITTED_SNAPSHOT才切到 MVCC
幻读到底什么时候发生，MVCC 真的能拦住吗
MVCC 本身不解决幻读。它靠保存旧版本数据来避免读写冲突，但对“新插入的行”，旧快照天然看不到，所以当另一个事务插入并提交了一条满足你 WHERE 条件的新记录，你再次执行相同查询，就会“多出一行”——这就是幻读。
MySQL InnoDB 在 REPEATABLE READ 下用间隙锁（Gap Lock）锁住索引区间，让别人插不进符合条件的行，这才压住了幻读。但这个机制只在有索引可依附时生效；如果查询条件没走索引，InnoDB 会退化成锁全表，性能雪崩。
- 幻读典型触发场景：
SELECT * FROM orders WHERE status = 'pending'，然后别人INSERT INTO orders (...) VALUES ('pending') - MVCC 快照里没有“未来插入的行”，所以它不负责幻读，别指望靠它兜底
- 显式加
SELECT ... FOR UPDATE或LOCK IN SHARE MODE能强制上锁，但会阻塞并发，且只对当前查询生效，不是事务级防护
SERIALIZABLE 是不是一劳永逸
它确实是唯一 SQL 标准定义下能彻底杜绝脏读、不可重复读、幻读的隔离级别，但代价是几乎把并发读写变成串行。MySQL InnoDB 实现 SERIALIZABLE 时，会把所有普通 SELECT 隐式转成 SELECT ... LOCK IN SHARE MODE，意味着读也要抢锁。
这不是“慢一点”的问题，而是容易引发锁等待超时（Lock wait timeout exceeded）、死锁（Deadlock found when trying to get lock），尤其在高并发聚合查询或报表场景下，可能直接拖垮整个业务链路。
- 很多应用误开
SERIALIZABLE后发现接口响应从 50ms 涨到 2s+，查日志全是Lock wait timeout exceeded - 它不能跨库、跨服务起作用，微服务里单个 DB 设成
SERIALIZABLE，对外部服务的调用依然可能引入不一致 - 真正需要强一致的场景（如金融记账），往往要配合应用层重试、幂等、补偿事务，而不是只靠数据库隔离级别硬扛
该不该关掉 MVCC，改用纯锁方案
关 MVCC（比如 MySQL 关 innodb_file_per_table 或强行设 tx_isolation=SERIALIZABLE）不会提升一致性，只会让系统更脆。MVCC 的价值不在“有没有幻读”，而在“能不能撑住读多写少的流量”。没有它，连首页商品列表这种简单查询都可能卡住下单事务。
真实瓶颈往往不在隔离级别选低了，而在没索引导致间隙锁失效、或长事务拖着快照不释放（information_schema.INNODB_TRX 里查 TRX_ROWS_LOCKED 和 TRX_STARTED 就能定位）。
- 检查是否真有长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 60 - 确认查询是否走了索引：
EXPLAIN SELECT ...看key和extra字段，避免Using filesort或Using temporary - MVCC 的 undo log 占空间，但比锁表导致请求堆积更可控；清理靠
innodb_purge_threads和innodb_max_purge_lag，不是靠关功能
实际项目里，95% 的一致性问题不出在隔离级别选错，而出在事务边界没理清、查询没走索引、或者把数据库当队列用（比如用 SELECT FOR UPDATE 做分布式锁）。MVCC 和 Serializable 都是工具，不是银弹。
