SQL事务隔离级别需按业务权衡准确性与性能：READ UNCOMMITTED易脏读，READ COMMITTED防脏读但存不可重复读，REPEATABLE READ防前两者（MySQL需显式锁防幻读），SERIALIZABLE最严但性能差；应结合场景选型并优化锁、索引与事务粒度。
SQL事务隔离级别不是越高级越好，关键看业务场景是否真需要强一致性。盲目用串行化（SERIALIZABLE）可能让并发性能断崖下跌，而读未提交（READ UNCOMMITTED）又容易引发脏读——选对隔离级别，本质是权衡“数据准确”和“系统吞吐”之间的平衡点。
搞清四个标准隔离级别到底在防什么
SQL标准定义了四种隔离级别，核心差异在于对三类并发问题的防护能力：
-
脏读（Dirty Read）：读到其他事务还没提交的数据。READ UNCOMMITTED 允许，其余都不允许。
-
不可重复读（Non-Repeatable Read）：同一事务中两次读同一行，结果不一致（因被其他事务更新并提交）。READ COMM
ITTED 防不住，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本身写法有问题。
基本上就这些。事务隔离不是魔法开关，它是数据库在并发世界里的“交通规则”。理解每条规则管什么、谁会踩线、怎么划车道，比记住四个名字重要得多。
ITTED 防不住，REPEATABLE READ 及以上可避免。