读未提交（read uncommitted）允许读到未提交数据，因其完全不加读锁、不依赖一致性视图，select直接读取最新行版本且不做trx_id可见性判断；脏读本质是读到后续可能回滚的无效数据，如事务a更新后未提交即被事务b读取并误用，a回滚后b所持数据即为“脏数据”。
读未提交（READ UNCOMMITTED）为什么允许读到未提交的数据
因为该隔离级别完全不加读锁，也不依赖一致性视图（consistent view），SELECT语句直接读取最新写入的行版本，不管它是否属于已提交事务。InnoDB 的行记录里有隐藏字段 trx_id，但在此级别下，引擎不做 trx_id 可见性判断——只要物理数据存在，就返回。
脏读发生的典型链路
关键不是“能不能读”，而是“读到了不该信的结果”。常见触发路径如下：
- 事务 A 执行
UPDATE account SET balance = 800 WHERE id = 1，但卡在COMMIT前 - 事务 B 在同一时刻执行
SELECT balance FROM account WHERE id = 1 - 事务 B 立刻拿到
800，并可能基于此做下游决策（如发货、放款） - 事务 A 随后执行
ROLLBACK，数据库实际余额回到1000 - 事务 B 持有的
800成为无效状态，即“脏数据”
为什么其他级别能避免脏读
区别在于是否引入“提交可见性检查”：
-
READ COMMITTED：每次SELECT都生成新的快照，只包含已提交事务的修改 -
REPEATABLE READ：事务启动时固定一个快照，后续所有读都基于它，跳过未提交变更 -
SERIALIZABLE：对读操作加gap lock或next-key lock，强制串行化
而 READ UNCOMMITTED 连最基础的提交检查都跳过，等于把 MVCC 机制关了一半。
实际中几乎没人用，但调试时容易误设
生产环境基本不会显式设成 READ UNCOMMITTED，但要注意两种隐性风险：
- 开发本地 MySQL 实例可能被手动执行过
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED，后续会话沿用 - 某些 ORM（如旧版 Django）或连接池配置错误，导致全局默认隔离级别被降级
查当前会话级别用 SELECT @@tx_isolation；查全局默认用 SELECT @@global.transaction_isolation。一旦发现是 READ-UNCOMMITTED，得立刻追查来源——这不是性能优化，是数据安全缺口。
