SQL 事务隔离级别需按业务权衡准确性与性能：READ UNCOMMITTED 易脏读，READ COMMITTED 防脏读但存不可重复读，REPEATABLE READ 防前两者（MySQL 需显式锁防幻读），SERIALIZABLE 最严但性能差；应结合场景选型并优化锁、索引与事务粒度。
SQL 事务隔离级别不是越高级越好，关键看业务场景是否真需要强一致性。盲目用串行化（SERIALIZABLE）可能让并发性能断崖下跌，而读未提交（READ UNCOMMITTED）又容易引发脏读——选对隔离级别，本质是权衡“数据准确”和“系统吞吐”之间的平衡点。
搞清四个标准隔离级别到底在防什么
SQL 标准定义了四种隔离级别，核心差异在于对三类并发问题的防护能力：
- 脏读（Dirty Read）：读到其他事务还没提交的数据。READ UNCOMMITTED 允许，其余都不允许。
- 不可重复读（Non-Repeatable Read）：同一事务中两次读同一行，结果不一致（因被其他事务更新并提交）。READ COMMITTED 防不住，REPEATABLE READ 及以上可避免。
- 幻读（Phantom Read）：同一事务中两次执行相同范围查询，返回行数不同（因其他事务插入 / 删除了符合 WHERE 条件的新行）。REPEATABLE READ 在多数数据库（如 MySQL InnoDB）通过间隙锁能防住，SERIALIZABLE 则彻底锁定范围。
注意：PostgreSQL 的 REPEATABLE READ 实际行为更接近 SERIALIZABLE（快照隔离 + 冲突检测），而 MySQL 的 REPEATABLE READ 默认不锁间隙，需配合 SELECT … FOR UPDATE 或 LOCK IN SHARE MODE 显式加锁才能防幻读。
按业务类型反推合适隔离级别
别背概念，直接对照常见场景选：
- 报表统计、日志分析、后台批处理：数据允许轻微延迟或近似值 → 用 READ COMMITTED 完全够用，开销小、并发高。
- 用户账户余额查询 + 扣款（如支付下单）：必须保证“查到的余额没被改过”→ REPEATABLE READ 更稳妥，避免查完就扣错钱。
- 库存超卖防控（如秒杀）：既要防更新丢失，又要防新插入的库存记录干扰判断 → 建议 REPEATABLE READ + 显式范围锁（SELECT … FOR UPDATE），或直接用应用层分布式锁 + 乐观锁兜底。
- 金融 级账务核对、审计追溯：要求绝对事务顺序与结果可重现 → 才考虑 SERIALIZABLE，但务必压测并发性能，通常需配合分库分表或异步补偿。
优化不是只调隔离级别，得配套做这几件事
隔离级别只是起点，真正影响效率的是它背后的锁行为和 MVCC 实现方式：
- 少用长事务：一个跑了 10 分钟的 REPEATABLE READ 事务，会拖住大量 undo 日志和行锁，让其他事务排队。把大事务拆成小步骤，查完立刻提交。
- 写操作尽量走索引：无索引 UPDATE/DELETE 会升级为表锁，在 READ COMMITTED 下也卡人；有索引才能精准加行锁，提升并发。
- 读多写少场景优先用 MVCC 快照读：比如 MySQL 里普通 SELECT 不加锁，靠 undo log 提供一致性视图；只有显式加锁（FOR UPDATE / LOCK IN SHARE MODE）才触发当前读，该省则省。
- 监控锁等待和死锁日志：MySQL 看 SHOW ENGINE INNODB STATUS，PostgreSQL 查 pg_locks 和 pg_stat_activity，快速定位是隔离级别太高，还是 SQL 本身写法有问题。
基本上就这些。事务隔离不是魔法开关，它是数据库在并发世界里的“交通规则”。理解每条规则管什么、谁会踩线、怎么划车道，比记住四个名字重要得多。
