READ UNCOMMITTED 允许脏读，因可读取未提交数据；解决脏读应避免降级隔离级别，而需通过显式加锁、原子操作或分布式锁等手段从源头规避。
READ UNCOMMITTED 不能解决脏读问题——它恰恰是唯一允许脏读的隔离级别。
为什么 READ UNCOMMITTED 会导致脏读
该级别下，事务可以读取其他事务尚未提交的修改。一旦写入事务回滚，读到的数据就是“不存在的”，即脏数据。
- 典型现象：
SELECT返回了后续被ROLLBACK的行，应用逻辑基于错误状态执行（如重复发券、误判库存） - MySQL 8.0+ 默认仍是
REPEATABLE READ，显式设为READ UNCOMMITTED属于主动降级隔离强度 - 即使只在单条
SELECT中用SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED，也仅对该事务生效，无法“修复”脏读，只会放大风险
真正需要解决脏读时该怎么做
脏读是异常现象，说明业务逻辑或并发控制有缺陷。应从源头规避，而非用更低隔离级别掩盖。
- 确认是否真有脏读：检查是否漏写了
COMMIT或误用了ROLLBACK；用SHOW ENGINE INNODB STATUS查未提交事务 - 优先用
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE显式加锁，配合合理事务边界 - 若为高并发计数/状态更新场景，改用原子操作：
UPDATE t SET cnt = cnt + 1 WHERE id = ?，避免先查后更 - 必要时升级到
SERIALIZABLE（但性能代价大），或引入应用层分布式锁（如 Redis 锁）控制关键路径
READ UNCOMMITTED 唯一合理的使用场景
仅限对一致性无要求、可容忍脏数据的离线分析类查询，例如监控大盘中“近似实时”的活跃连接数估算。
- 必须确保：结果不参与任何决策逻辑、不写入下游系统、用户明确知晓数据可能不准
- 不能用于任何涉及金额、状态机、权限校验等敏感路径
- MySQL 8.0+ 中仍支持该级别，但 InnoDB 实际会忽略部分锁（如 gap lock），导致幻读比预期更严重
把隔离级别调低不是解法，而是把问题推给上层业务去兜底。多数所谓“临时解决脏读”的尝试，最后都变成了排查更难复现的数据不一致事故。
