SQL事务隔离级别直接影响查询准确性，共四类：1. READ UNCOMMITTED允许脏读；2. READ COMMITTED避免脏读但存在不可重复读；3. REPEATABLE READ防止前两者但仍有幻读风险；4. SERIALIZABLE通过强制串行化杜绝所有问题但性能最差。
SQL事务隔离不是抽象概念，而是直接影响查询结果准确性的实际机制。它解决的核心问题是：当多个事务同时操作同一数据时，如何避免脏读、不可重复读和幻读。关键不在背级别定义，而在理解每个隔离级别对“读一致性”的保障边界。
READ UNCOMMITTED：能读到别人还没提交的“脏数据”
这是最低隔离级别，几乎不加读锁。一个事务可以读取另一个未提交事务修改过的行。
常见场景：
- 实时监控类应用（如秒级库存看板），允许短暂误差；
- 调试或日志分析，需要快速看到中间状态；
- 但绝不能用于资金、订单、积分等强一致性业务。
示例：事务A更新用户余额为1000，尚未提交；事务B此时SELECT该用户余额，读到1000——若事务A随后回滚，事务B就基于错误数据做了后续操作。
READ COMMITTED：只读已提交的数据，但同一事务内多次读可能不一致
Oracle、SQL Server默认级别。每次SELECT都生成新快照，因此两次读之间若被其他事务修改并提交，结果会不同。
典型影响：
- 订单支付中，“查余额→扣款”两步间余额被他人充值，导致扣款前余额充足、扣款时却不足；
- 报表统计中，上午查了用户数，下午再查发现多出几条——不是数据错了，是别的事务插入并提交了。
应对建议：
- 关键业务逻辑尽量合并为单条语句（如UPDATE ... WHERE balance >= ?）；
- 必须分步时，用SELECT FOR UPDATE显式加行锁（需配合事务开启）。
REPEATABLE READ：保证事务内读结果“可重复”，但幻读仍可能发生
MySQL InnoDB默认级别。事务启动时创建一致性视图（Read View），整个事务期间所有SELECT都基于这个快照。
它能防止脏读、不可重复读，但对“新插入的行”无感知——这就是幻读。
真实案例：
- 某银行批量放贷脚本：先SELECT WHERE status = 'pending' 得到100条待处理记录；
- 处理过程中，另一事务插入10条新的pending记录并提交；
- 原脚本第二次SELECT同条件，仍只看到100条（因为快照固定），但UPDATE ... WHERE status = 'pending' 却可能更新到110行（InnoDB用间隙锁+行锁阻止插入，但纯SELECT不触发锁）。
注意：MySQL通过Next-Key Lock在RR下基本解决了幻读（针对当前读），但快照读仍不感知新行。所以“是否幻读”，取决于你用的是SELECT还是SELECT ... FOR UPDATE。
SERIALIZABLE：最严隔离，靠锁表或锁范围实现串行执行
强制事务串行化，所有SELECT自动转为SELECT ... LOCK IN SHARE MODE，写操作加排他锁。并发性能最低，但数据最安全。
适用场景：
- 财务月结、账务核对等不允许任何并发干扰的批处理；
- 小型系统中对一致性要求极高、且QPS极低的管理后台操作。
风险提示：
- 容易引发死锁，尤其多表关联更新时；
- 长事务会持续持锁，阻塞其他业务，线上慎用；
- 不是“万能解药”，反而可能掩盖设计问题（如应拆分大事务为小步骤+补偿）。
本质上，隔离级别选型是业务容忍度与系统性能的权衡。没有“最好”，只有“最适合”。多数Web应用用READ COMMITTED足够，金融核心用REPEATABLE READ+主动加锁，而SERIALIZABLE更多是兜底手段。不复杂但容易忽略——真正决定数据正确的，往往不是语法多炫，而是你有没有在SELECT前想清楚：“这一行，此刻我该不该信？”
