读未提交几乎没人用，因为它允许事务读取未提交的脏数据，一旦写入事务回滚，读取结果即错误，业务无法接受这种不确定性，仅极少数日志分析类临时查询试探使用。
读未提交（READ UNCOMMITTED）为什么几乎没人用
这个级别允许事务读到其他事务还没 COMMIT 的修改，也就是“脏数据”。一旦写入事务回滚，读出来的结果就是错的——业务上根本没法接受这种不确定性。
- 典型错误现象：
SELECT返回了后续被回滚的值，比如查到用户余额为负，但其实那笔扣款根本没成功 - 真实场景极少：只在极少数日志类、分析类且允许误差的临时查询中试探性使用
- 性能不比其他级别高多少，却完全放弃一致性底线，得不偿失
读已提交（READ COMMITTED）如何避免脏读但仍有风险
MySQL 默认不是它，但 PostgreSQL 和 Oracle 默认是。它保证你读到的一定是已提交的数据，解决了脏读，但同一事务内两次 SELECT 同一行可能得到不同结果——因为中间有别的事务改完并提交了。
- 不可重复读示例：事务 A 第一次查订单状态是
'pending'，事务 B 提交更新为'shipped'，A 再查就变成'shipped' - 幻读依然存在：B 在 A 两次查询之间插入新订单，A 第二次会多出一行
- InnoDB 用“每次查询都新建快照”实现，开销略高于 RR，但并发度更高
可重复读（REPEATABLE READ）为何是 MySQL 默认且最常用
它让事务从启动那一刻起，所有 SELECT 都基于同一个数据快照，所以同一条记录反复读一定一致。这是大多数 Web 应用能接受的平衡点：强一致性 + 可控并发。
- 幻读没彻底解决：范围查询（如
SELECT * FROM orders WHERE status = 'pending'）仍可能因其他事务INSERT新行而结果集变长 - InnoDB 用间隙锁（Gap Lock）+ Next-Key Lock 抑制部分幻读，但不是靠隔离级别本身，而是引擎实现细节
- 注意：
UPDATE/DELETE语句的 where 条件命中索引时才加间隙锁；全表扫描或无索引字段会导致锁整张表
串行化（SERIALIZABLE）真能杜绝一切问题？代价是什么
它强制事务串行执行，所有 SELECT 都隐式加共享锁，写操作加排他锁。理论上彻底消灭脏读、不可重复读、幻读——但代价是并发能力断崖式下跌。
- 常见卡顿现象：两个事务同时查同一行，第二个会一直等第一个释放锁，超时抛出
Lock wait timeout exceeded - 仅适合极低频、强一致性要求的场景，比如金融核心账务批处理、审计对账脚本
- 别误以为“设成 SERIALIZABLE 就万无一失”——锁冲突导致死锁概率上升，反而更难 debug
真正影响并发性的从来不是隔离级别名字本身，而是它背后触发的锁行为和 MVCC 快照策略。RR 看似“高隔离”，实际靠的是 InnoDB 的优化实现；而 RC 虽然“低一级”，在某些高读低写场景下吞吐反而更好。选哪个，得看你的 SQL 是否大量依赖多次读一致性，以及能不能容忍幻读带来的逻辑绕弯。
