【发布时间】:2015-02-21 10:53:26
【问题描述】:
在https://msdn.microsoft.com/en-us/en-en/library/ms190805.aspx 中提到的称为“行更新导致的缺失和双重读取”的并发效应是否与 Innodb 引擎相关?
例如:
在 READ UNCOMMITTED 级别运行的事务不会发出共享锁以防止其他事务修改当前事务读取的数据。在 READ COMMITTED 级别运行的事务确实会发出共享锁,但行或页锁在读取行后会被释放。在任何一种情况下,当您扫描索引时,如果另一个用户在您读取期间更改了该行的索引键列,则如果键更改将该行移动到扫描之前的位置,则该行可能会再次出现。同样,如果键更改将行移动到索引中您已读取的位置,则该行可能不会出现。为避免这种情况,请使用 SERIALIZABLE 或 HOLDLOCK 提示,或行版本控制
还有一个更新。从 MSSQL 引擎: "Microsoft SQL Server 2008 内部"
在某些情况下,扫描最终可能会返回多次出现的行,甚至会跳过行。分配顺序扫描比索引顺序扫描更容易出现这种行为。我将首先描述分配顺序扫描如何发生这种现象以及在何种情况下会发生这种现象。然后我将解释如何在索引顺序扫描中发生这种情况。分配顺序扫描 图 4-30 分三个步骤演示了分配顺序扫描如何返回多次出现的行。第 1 步显示正在进行的分配顺序扫描,按文件顺序(不是索引顺序)读取某些索引的叶页。已经阅读了两页(键 50、60、70、80、10、20、30、40)。此时,在读取索引的第三页之前,有人使用键 25 将一行插入到表中。步骤 2 显示了在作为插入目标的页面中发生的拆分,因为该页面已满。作为分割的结果,一个新的页面被分配了——在我们的例子中,在文件后面的一个扫描还没有到达的点上。来自原始页面的一半行移动到新页面(键 30、40),并且具有键 25 的新行由于其键值而被添加到原始页面。步骤 3 显示了扫描的继续:读取剩余的两页(键 90、100、110、120、30、40),包括由于拆分而添加的那一页。请注意,键为 30 和 40 的行被第二次读取。
【问题讨论】:
-
还有一个更新。来自 MSSQL 引擎: