Oracle 不允许脏读，因此甚至不允许从 JDBC 设置 Read Uncommitted。
postgresql在选择无读取时也会回到读取。
。SQL Server 定义了一个 Read Uncommitted 隔离级别，因为它的并发控制模型是基于锁定的(除非切换到两个快照隔离级别)，所以它可能是唯一一个可以通过避免锁定报告来获得一些性能优势的数据库并不真的需要严格的一致性。
InnoDB 也使用 MVCC，但与 Oracle 和 PostgreSQL 不同，它允许脏读。为什么会这样？直接转到最新版本而不是从回滚段重建以前的版本是否有任何性能优势？回滚段查询时间恢复如此密集的过程是否需要允许脏读？
最佳答案
我知道的主要优点是，如果您的所有 session 都是 READ-UNCOMMITTED，那么内务处理(清理 UNDO)将永远不会阻塞等待旧 session 。
如果不需要为 READ-UNCOMMITTED 事务本身创建读取 View 结构 (example)，可能会有一些其他的性能提升，但我自己还没有证实这一点。一般来说，这不是 InnoDB 团队优化目标的隔离级别。
编辑:就展开回滚段的性能而言，是的，许多修订可能会很慢。 AFAIK 这是一个简单的链接列表，可能需要多次遍历。在这里很难与 PostgreSQL 进行比较，因为体系结构(mysql 具有 UNDO 功能)非常不同。一般来说，当重定位“仅符合逻辑+适合工作集”时，我会说 UNDO 工作得很好；即它在内存中执行，但在需要物理 IO 之前被清理。
关于mysql - MySQL InnoDB如何实现Read Uncommitted隔离级别，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33223460/