SQL事务隔离通过不同级别控制并发事务间的可见性：READ UNCOMMITTED允许脏读；READ COMMITTED防止脏读但存在不可重复读；REPEATABLE READ防止前两者，InnoDB用间隙锁缓解幻读；SERIALIZABLE彻底串行化但性能差。
SQL事务隔离解决的是多个事务并发执行时，彼此之间如何“看不见”对方未提交的修改、避免读到脏数据、重复读不一致等问题。核心不是“锁住整个表”，而是通过隔离级别控制“能看到什么、不能看到什么”。下面用高频场景带你直观理解。
脏读：读到了别人还没提交的“废稿”
场景：电商秒杀，用户A下单扣减库存，但中途点了取消，事务回滚；用户B此时查库存，发现少了1件——其实那笔扣减根本没生效。
原因：B用了READ UNCOMMITTED（最低隔离级），直接读了A未提交的中间状态。
怎么防？
- 默认别用 READ UNCOMMITTED，MySQL 默认是 REPEATABLE READ，PostgreSQL 默认是 READ COMMITTED
- 只要把隔离级设为 READ COMMITTED 或更高，B就只能看到已提交的数据，自动过滤掉A的“废稿”
不可重复读：同一事务里，两次 SELECT 结果不一样
场景：银行转账前查余额（SELECT balance），中间别人给该账户打了款（UPDATE + COMMIT），你再查一次，余额变了——导致你按旧余额做逻辑判断（比如拒绝转账），实际已不准确。
这是 READ COMMITTED 的典型表现：每次 SELECT 都读最新已提交快照，所以两次结果可能不同。
怎么稳住？
- 升级到 REPEATABLE READ（MySQL 默认）：事务内第一次 SELECT 后，后续所有 SELECT 都基于同一快照，值不会变
- 注意：这不等于“锁住行”，而是 MVCC 快照机制在起作用——不是靠锁，是靠“时间切片”
幻读：同条件 SELECT，前后查出的行数对不上
场景：管理员统计“订单状态=待支付”的数量（SELECT COUNT(*) WHERE status='pending'），得到100条；接着财务批量更新了一批订单为“已支付”；管理员再跑同样语句，发现只剩95条——看起来像“凭空消失”了5条，这就是幻读（更准确说是“幻行消失”；插入导致的“多出来”也属幻读）。
REPEATABLE READ 能防不可重复读，但对幻读——MySQL InnoDB 用间隙锁（Gap Lock）+ Next-Key Lock 在可重复读下基本挡住插入型幻读；但纯 UPDATE/DELETE 匹配范围时，仍可能因其他事务 INSERT 新匹配行而出现幻象。
真正封死幻读？
- 用 SERIALIZABLE：所有 SELECT 自动加共享锁，INSERT/UPDATE/DELETE 加排他锁，彻底串行化——性能代价大，一般不用
- 更实用做法：业务层显式加锁（如 SELECT ... FOR UPDATE）或用唯一约束+重试逻辑，比盲目升隔离级更可控
怎么选？看业务容忍度，不堆最高就行
不是隔离级别越高越好。SERIALIZABLE 像给数据库戴全盔，安全但笨重；READ COMMITTED 像戴头盔，防撞又灵活；REPEATABLE READ 是 MySQL 默认平衡点，兼顾一致性与并发。
建议：
- 普通 Web 应用（用户资料、订单查询）→ 用默认 REPEATABLE READ（MySQL）或 READ COMMITTED（PostgreSQL）足够
- 金融类强一致性场景 → 关键事务显式加 SELECT ... FOR UPDATE 或用乐观锁（version 字段）更精准
- 报表类只读长事务 → 可临时设 READ UNCOMMITTED（仅限允许脏读的离线分析），但需明确标注风险
基本上就这些。隔离级别不是魔法开关，而是帮你划清“可见边界”的标尺——懂场景、知边界、选合适，比死记级别定义管用得多。
