事务隔离级别控制事务间数据可见性，SQL标准定义四级：READ UNCOMMITTED（脏读）、READ COMMITTED（不可重复读）、REPEATABLE READ（幻读）、SERIALIZABLE（串行化）；实际效果依赖数据库实现，需按业务容忍度选型，避免盲目高隔离引发性能问题。
SQL事务隔离不是设置个参数就完事，它直接决定你查到的数据是不是“当下真实”的——尤其在高并发改写场景下，读到旧数据、重复记录、甚至幻影行，往往不是代码写错了，而是隔离级别没选对。
事务隔离级别到底在隔离什么？
核心是控制一个事务能看到其他并发事务的哪些修改。SQL标准定义了四个级别，但实际效果要看数据库实现：
- READ UNCOMMITTED：能读到别人还没提交的脏数据（脏读），极少用，除非明确接受风险
- READ COMMITTED：只读已提交数据，但同一事务内多次查询可能结果不一致（不可重复读）
- REPEATABLE READ：保证同一事务中多次读取相同范围数据结果一致，但可能遇到幻读（新插入的行突然出现）
- SERIALIZABLE：最高级别，加范围锁或MVCC快照锁定，基本串行执行，性能代价最大
真实案例：库存扣减为什么超卖？
电商秒杀场景，两个用户几乎同时下单同一商品（库存=1）：
事务A和B都执行：
SELECT stock FROM items WHERE id = 1001; → 都读到 stock = 1
然后都执行：
UPDATE items SET stock = stock - 1 WHERE id = 1001 AND stock >= 1;
如果数据库默认是 READ COMMITTED（如 PostgreSQL 默认），两次 UPDATE 都会成功——因为 SELECT 和 UPDATE 不是一体的，中间没有锁住该行；结果 stock 变成 -1。
解法不是加锁语句，而是升级隔离级别：
在 PostgreSQL 中设为 REPEATABLE READ，第一次 SELECT 后，后续 UPDATE 会基于快照判断是否可执行；MySQL InnoDB 的 REPEATABLE READ 则通过间隙锁阻止新插入，也能避免超卖（但注意：MySQL 的 RR 并不完全等价于标准定义）。
复杂查询中的隐式陷阱：分页+实时统计
后台要展示「最近订单列表 + 总数」，写两个语句：
SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 0;
SELECT COUNT(*) FROM orders;
在 READ COMMITTED 下，这两条语句各自读取不同时间点的快照——总数可能是 1000，但第一页只查出 19 条（因有新订单插入导致排序偏移）。用户看到「共1000单，只显示20条」，却翻不到最后一页。
解决思路：
• 改用 REPEATABLE READ，让两个查询共享同一快照
• 或更稳妥：用单条语句带窗口函数 SELECT *, COUNT(*) OVER() AS total FROM orders ... LIMIT 20
• 不依赖隔离级别，逻辑自洽
怎么选？看业务容忍度，不是越高越好
盲目上 SERIALIZABLE 会导致大量锁等待、死锁、响应变慢。实际建议：
- 报表类查询：READ COMMITTED 完全够用，还省资源
- 账户余额、库存、支付确认：必须 REPEATABLE READ 或显式 SELECT ... FOR UPDATE
- 金融级对账、跨库一致性校验：才考虑 SERIALIZABLE 或应用层补偿
- 永远检查你用的数据库具体行为——MySQL、PostgreSQL、SQL Server 对同一名字的隔离级别实现差异很大
基本上就这些。事务隔离不是银弹，但它是一把精准的刻刀——用对了，复杂查询稳如磐石；用错了，问题藏得深、复现难、排查苦。
