事务隔离级别需按业务场景选择：read uncommitted易脏读，read committed防脏读但有不可重复读，repeatable read防前两者但幻读仍可能，serializable彻底避免三类问题但并发差；mysql与postgresql实现有差异，应结合压测和监控优化选级。
事务隔离级别不是越高越好，也不是越低越安全，关键看业务场景对数据一致性的容忍度和并发压力的实际需求。选错级别，轻则性能下降、锁冲突频发，重则出现脏读、不可重复读甚至幻读，影响核心业务逻辑。
读懂四个标准隔离级别到底在防什么
SQL标准定义了四种隔离级别，本质是逐步限制“一个事务能看到另一个事务未提交或已修改但未提交的数据”的范围：
- READ UNCOMMITTED：不加读锁，允许读取其他事务未提交的变更——可能脏读。极少用于生产，仅适合日志类、统计类等对一致性无要求的场景。
- READ COMMITTED：每次 SELECT 都加瞬时读锁，只读已提交数据——避免脏读，但同一事务内多次读可能结果不同（不可重复读）。
- REPEATABLE READ：事务启动时快照一次数据（如 MySQL InnoDB 的 MVCC），后续读都基于该快照——解决不可重复读，但不保证范围查询不出现新行（幻读仍可能发生，InnoDB 通过间隙锁部分抑制）。
- SERIALIZABLE：最高级别，所有读操作隐式加范围锁，强制串行执行——彻底避免脏读、不可重复读、幻读，但并发能力急剧下降，容易死锁。
常见业务场景怎么选才不踩坑
别背理论，看实际逻辑流：
-
订单支付扣减库存：必须防止超卖，需保证“查库存→判断→扣减”原子性。用 REPEATABLE READ（MySQL 默认）足够，配合
SELECT ... FOR UPDATE显式加行锁，比 SERIALIZABLE 更高效且可控。 - 用户余额查询+展示：仅读取，不要求强一致性，READ COMMITTED 即可。避免因长事务阻塞他人更新，也减少 MVCC 版本链开销。
-
财务对账汇总报表：要求某一时点全量数据严格一致，不能边算边被改。适合 REPEATABLE READ 或显式开启一致性快照（如 PostgreSQL 的
BEGIN REPEATABLE READ），而非盲目升到 SERIALIZABLE。 - 高并发秒杀写入：大量 INSERT/UPDATE 竞争同一索引范围。若用 SERIALIZABLE 或过度依赖间隙锁，极易锁表或死锁。此时应降级为 READ COMMITTED + 应用层幂等+唯一索引约束，把一致性保障前移到写入环节。
MySQL 和 PostgreSQL 的关键差异要留意
同名隔离级别，在不同数据库实现机制和效果可能不同：
- MySQL InnoDB 的 REPEATABLE READ 默认启用 MVCC 快照，但幻读仍可通过
INSERT触发（间隙锁只覆盖已有记录间的空隙）；而 PostgreSQL 的 RR 级别真正实现了快照隔离（SI），从语义上杜绝幻读。 - PostgreSQL 没有真正的 SERIALIZABLE——它的“SERIALIZABLE”是可串行化快照隔离（SSI），通过检测写偏（write skew）自动回滚冲突事务，性能比传统锁方案好，但仍有失败重试成本。
- MySQL 的 READ COMMITTED 每次查询都新建快照，适合读多写少；PostgreSQL 的 RC 级别也是语句级快照，行为接近。
实用建议：从监控和压测反推合理级别
别靠猜，用数据说话：
- 上线前做并发压测，观察
innodb_row_lock_waits（MySQL）或pg_stat_database.deadlocks（PG）是否陡增——若频繁锁等待，可能是隔离级别过高或缺少索引导致锁粒度变大。 - 检查慢查询日志中是否有大量
SELECT ... FOR UPDATE或锁等待超时，结合业务路径判断是否真需要强一致性，还是可用应用层补偿（如异步校验、最终一致）替代。 - 对核心交易表，宁可默认用 REPEATABLE READ + 显式锁控制，也不盲目设 SERIALIZABLE；对报表、分析类库，直接设 READ COMMITTED 甚至更低，并关闭 autocommit 减少事务开销。
