SQL事务隔离如何控制_真实案例解析强化复杂查询思维【教程】

事务隔离级别控制事务间数据可见性，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 并不完全等价于标准定义）。

复杂查询中的隐式陷阱：分页+实时统计

后台要展示「最近订单列表 + 总数」，写两个语句：

标签： mysql 金融 为什么 有锁