2

Oracle 不允许脏读，因此甚至不允许从 JDBC 设置 Read Uncommitted。

PostgreSQL also falls back to Read Committed, when choosing Read Uncommitted.

SQL Server 定义了 Read Uncommitted 隔离级别，因为它的并发控制模型是基于锁定的（除非切换到两个快照隔离级别），因此它可能是唯一可以从避免锁定报告中看到一些性能优势的数据库确实需要严格的一致性。

InnoDB 也使用 MVCC，但与 Oracle 和 PostgreSQL 不同的是，它允许脏读。为什么会这样？直接转到最新版本而不是从回滚段重建以前的版本是否有任何性能优势？回滚段查询时间是否恢复了需要允许脏读的密集过程？

4

1 回答 1

1

我知道的主要优点是，如果您的所有会话都是未提交的，那么内务管理（清理 UNDO）将永远不会被阻止等待旧会话。

如果不需要为 READ-UNCOMMITTED 事务本身创建读取视图结构（示例），则可能会有其他一些性能提升，但我自己没有确认这一点。一般来说，这不是 InnoDB 团队优化目标的隔离级别。

编辑：就展开回滚段的性能而言，是的，许多修订可能会很慢。AFAIK 它是一个简单的链接列表，可能需要许多遍历。这里很难与 PostgreSQL 进行比较，因为架构（mysql 功能 UNDO）完全不同。一般来说，当重定位是“仅逻辑+适合工作集”时，我会说 UNDO 效果很好；即它在内存中执行，但在需要物理 IO 之前已清理。

于 2015-10-19T21:25:05.590 回答