READ UNCOMMITTED下必然发生脏读：事务B可读取事务A未提交的修改，若A回滚，B已基于错误中间态执行逻辑，导致对账错误、风控误判、库存显示失真；InnoDB在此级别跳过MVCC，SELECT直接读最新物理行且不加锁。
读未提交（READ UNCOMMITTED）下脏读的典型表现
事务 A 修改某行但没 COMMIT，事务 B 在同一时刻执行 SELECT 就能拿到这个“中间态”值——哪怕 A 随后 ROLLBACK，B 已经基于错误数据做了判断或计算。这不是偶发，而是该隔离级别下的确定行为。
脏读直接引发的业务逻辑崩坏场景
常见于对账、风控、库存预占等强一致性要求环节：
- 财务对账系统读到一笔未确认的转账扣款，生成错误的日报，次日发现该笔交易已回滚，但报表已下发
- 风控引擎读取用户临时冻结状态（事务 A 正在执行
UPDATE users SET status = 'frozen' WHERE id = 123但未提交），判定用户异常并拦截后续所有请求；而事务 A 实际因校验失败ROLLBACK，用户本应正常可用 - 电商下单页显示“库存剩余 5”，实际是事务 A 临时减了 5 但尚未提交；用户点击下单时库存已恢复为 10，但前端已按“5”做了渲染和限制
为什么 READ UNCOMMITTED 不提供 MVCC 快照
MySQL InnoDB 在 READ UNCOMMITTED 下跳过 MVCC 机制，所有 SELECT 都走**当前最新行版本 + 无锁物理读**。这意味着：
- 不访问
undo log，不构造一致性视图（consistent read view） -
SELECT不加S锁，也不触发隐式锁升级 - 写操作仍加
X锁，但读完全不参与锁协调——所以读写互不阻塞，但也彻底放弃数据可信边界
设置与验证 RU 隔离级别的风险操作
执行 SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 后，必须立刻验证是否生效：
查当前会话级别：SELECT @@session.tx_isolation —— 返回值应为 READ-UNCOMMITTED（注意连字符）；若返回 REPEATABLE-READ，说明未生效，可能是权限不足或被全局配置覆盖。
真正危险的是：它不会报错，也不会警告，只是静默地把脏数据暴露给你。你在开发环境跑通了逻辑，上线后遇到并发写入，就可能突然发现订单金额、用户状态、积分变动全都不对——而日志里找不到任何异常记录。
