SQL事务隔离核心是在性能与一致性间权衡，四种级别逐级防止脏读、不可重复读、幻读；MySQL InnoDB的REPEATABLE READ用间隙锁防大部分幻读，但非严格标准；选型需依业务容忍度，如日志用READ COMMITTED，转账用REPEATABLE READ，秒杀用乐观锁；排查应实测而非仅看文档。
SQL事务隔离的核心是解决并发访问时的数据一致性问题，不是靠“锁得越严越好”，而是根据业务场景在性能与一致性之间做精准取舍。
四种标准隔离级别到底在防什么
SQL标准定义了READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE四个级别，本质是逐级限制三类并发异常：
- 脏读：读到其他事务未提交的修改（仅READ UNCOMMITTED允许）
- 不可重复读：同一事务中两次SELECT同一条记录，结果不一致（因其他事务提交了UPDATE/DELETE）
- 幻读：同一事务中两次SELECT相同条件，返回行数不同（因其他事务插入或删除了匹配行）
注意：不可重复读侧重“行内容变化”，幻读侧重“行数量变化”。MySQL InnoDB的REPEATABLE READ通过间隙锁（Gap Lock）+行锁，已防止大部分幻读，但严格意义上仍可能在非唯一索引范围查询中出现。
主流数据库的实际行为≠标准定义
直接照搬SQL标准容易踩坑。关键差异点：
- PostgreSQL：完全遵循标准，REPEATABLE READ能真正阻止幻读（使用MVCC快照 + 行级谓词锁）
- MySQL InnoDB：REPEATABLE READ默认启用Next-Key Lock（行锁+间隙锁），能防幻读，但red">不支持可串行化快照读；SERIALIZABLE会自动将所有SELECT转为SELECT ... LOCK IN SHARE MODE
- SQL Server：READ COMMITTED默认用锁，但开启READ_COMMITTED_SNAPSHOT后改用行版本控制（RCSI），彻底避免读阻塞
实战建议：查清你用的数据库版本和配置（比如MySQL的tx_isolation、SQL Server的is_read_committed_snapshot_on），别只看文档标题。
怎么选？看业务容忍度，不是越高越好
隔离级别越高，锁竞争越激烈，吞吐量越低。选型逻辑很直接：
- 日志类、统计报表类读操作 → READ COMMITTED足够，避免长事务拖慢写入
- 银行转账、库存扣减等强一致性场景 → REPEATABLE READ（MySQL）或 SERIALIZABLE（需极严控制）
- 高并发秒杀 → 别死守隔离级别，用乐观锁（version字段）+重试，或Redis预减库存分流
- 纯只读分析系统 → 开启快照隔离（如PostgreSQL的REPEATABLE READ，SQL Server的RCSI），零阻塞
一个反例：电商订单详情页用SERIALIZABLE查用户信息，反而导致大量SELECT被阻塞——这里根本不需要防幻读，READ COMMITTED更合理。
动手排查：一眼识别当前隔离问题
别猜，用工具验证：
- MySQL：执行SELECT @@tx_isolation看会话级别；用SHOW ENGINE INNODB STATUS\G查锁等待
- PostgreSQL：查SELECT current_setting('transaction_isolation')；用pg_locks视图分析阻塞链
- 通用技巧：在测试环境模拟两个事务，分别UPDATE再SELECT，观察是否看到未提交值、是否被阻塞、第二次读是否变化——三步快速定位实际行为
记住：生产库上临时改隔离级别要谨慎，有些级别（如SERIALIZABLE）可能触发全表扫描或隐式锁升级。
基本上就这些。事务隔离不是背概念，而是理解“我在防什么、代价是什么、有没有更轻量的替代方案”。调对了，QPS翻倍；调错了，加再多索引也卡。
