所以，我有一些死锁问题。

我看到了两种解决方法。添加read uncommitted到我的数据库或执行快照隔离并添加read committed snapshot.

在对两者进行了一些研究之后，在我看来，它read uncommitted可以允许读取可能永远不会提交到数据库的数据。

另一方面，read committed snapshot只会提供最新的（它是最新的，对吗？）已提交的数据版本（即使数据可能处于更改/事务中间。）

这是正确的吗？

如果是这样，我倾向于快照隔离（我真的不想返回处于更改过程中的数据。）

但是，我的 DBA 告诉我，他最后听说快照隔离存在“问题”。（他没有详细说明问题所在，只是说它不是企业就绪功能。）

所以，这里是我关于快照隔离的问题：

快照隔离功能强大吗？它只是有效吗？

或者是否有我需要注意的“陷阱”？

假设一个SQLCmd会话正在使用事务隔离级别REPEATABLE READ。

在这个会话中，我开始一个事务并在非索引列上执行一个UPDATE带有WHERE子句的语句。该语句应该WHERE为表中的每条记录评估子句，但只有一条会匹配。

如果我在运行UPDATE语句后检查放置在此事务下的锁，我只能看到IXTable 和 Page 上的两个锁，以及X更新的行上的锁。

我的问题是：数据库引擎不应该在它读取的所有行上放置共享锁以确保REPEATABLE READ吗？如果某个其他事务更新了一条记录，使其与 UPDATE 语句中的 WHERE 子句匹配，从而违反了REPEATABLE READ.

如果我执行 a SELECT *，那么我可以看到它S在每一行上放置了锁，这些锁尚未用X.

任何人都可以帮助我了解这种情况吗？

我已经尝试过 SQL Server 2008 R2 和 2012，两者的行为相同。

可重复阅读

在SQL92的定义中，REPEATABLE READ是由几个条件定义的。

P1（“脏读”）：

1) P1（“脏读”）：SQL 事务 T1 修改一行。SQL 事务 T2 然后在 T1 执行 COMMIT 之前读取该行。如果 T1 然后执行 ROLLBACK，则 T2 将读取从未提交的行，因此可以认为该行从未存在过。

P2（“不可重复读取”）：

2) P2 ("Non-repeatable read")：SQL-transaction T1 读取一行。SQL 事务 T2 然后修改或删除该行并执行 COMMIT。如果 T1 然后尝试重新读取该行，它可能会收到修改后的值或发现该行已被删除。

原子性和no updates will be lost：

四个隔离级别保证每个 SQL 事务将完全执行或根本不执行，并且不会丢失任何更新。

表 9，其中定义REPEATABLE READ必须排除 P1 & P2：

表 9，“SQL 事务隔离级别和三种现象”指定了给定隔离级别可能和不可能的现象。

所以在SQL92的定义中REPEATABLE READ，必须排除P1、P2，并且支持原子性，没有更新丢失。

A5B（写偏斜）

另一方面，A5B（Write Skew）在A Critique of ANSI SQL Isolation Levels 中定义：

假设 T1 读取 x 和 …

维基百科说Read Committed 容易出现不可重复读取。但是，我可以简单地在我的事务中缓存第一个读取结果（制作快照）并释放数据库锁以让其他事务更新读取行。实际上，我以 RC 隔离为代价实现了重复读取，因此比可重复读取提供的性能更高。没有什么不好的事情发生，我可以像使用可重复读取隔离一样安全，对吗？不，我想对我读过的数据持有读锁可能有助于防止银行或预订预订中出现一些不良情况。哪个？

我正在寻找的是我的 RR 仿真失败的示例。我已经证明我可以通过在第一次读取访问时缓存数据项来使读取可重复。我想要一个我的模拟不够的例子。这种策略下读完立即释放锁有什么不好？

维基百科的文章和可重复阅读的名称在我看来暗示这就是我们所需要的。但我怀疑可重复读取通过使用共享锁，为了提供比简单读取一致性更重要的东西而牺牲了性能，因为后者可以通过简单的读取提交 + 缓存（快照）组合来实现。我猜读者锁在2PL 中的整个事务中持续存在，并且我们在多个读者/单作者中使用共享/读取锁，其目的不仅仅是在单个事务中提供可重复的读取，因此，Repeatable Read 是隐藏锁定事实的用词不当，它实际上牺牲了比一致性读取更大的性能。

我尝试了 SQL Server 数据库的各种配置，最终设置READ_COMMITTED_SNAPSHOT为ONwhile ALLOW_SNAPSHOT_ISOLATIONis OFF。

我注意到启用此功能后，许多查询的速度要快得多。我仍然使用默认READ COMMITTED隔离级别连接到数据库。

这里究竟发生了什么？我认为 when ALLOW_SNAPSHOT_ISOLATIONis OFF，设置READ_COMMITTED_SNAPSHOT为ON不会有任何影响......我实际上仍然没有使用快照隔离，还是我？有人可以解释一下吗？我糊涂了。

我尝试在网上研究这个主题，但是每当我看到READ_COMMITTED_SNAPSHOT有人使用它时，它总是与 一起使用ALLOW_SNAPSHOT_ISOLATION，而我没有启用它。

我正在运行 SQL Azure，我有以下案例。

我有两个事务W（作者）和R（读者）。两者都使用 RCSI（使用 LTM 的具有 TransactionScopes 的 .net 应用程序）运行。该R交易在同一时间启动W，并继续执行SELECT语句读取由该交易的书面表格W。

通常，事务R在W提交其更改后立即看到所有更改。但是，有时事务会R看到没有事务最近提交的状态W。

问题是：

RCSI 是否保证R始终看到表的最新状态？根据：https : //docs.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view= sql-server- 2017读提交应该总是获取在执行SELECT查询时可用的行的最新版本。但是，当有两个独立的会话时，是否可以保证？

我有一个启用了 RCSI 的数据库，并且从我记事起，我就一直在在线重建索引（SQL 2014 Enterprise）。我的理解是，如果我们要离线重建索引，我们将丢失额外的 14 个字节。但是，只要我们继续在线重建或重组，我们就会保留每行 14 个字节。那是对的吗？

MYSQL VERSION : 5.7.X
STORAGE ENGINE : Innodb

我有一个大致的想法，即 Read Committed Isolation 将主要使用 Shared and Exclusive Record Locks。但是，根据 mysql docs，在某些情况下，甚至 Read Committed 也必须使用间隙锁定。

READ COMMITTED ..... 对于锁定读取（SELECT with FOR UPDATE 或 LOCK IN SHARE MODE）、UPDATE 语句和 DELETE 语句，InnoDB 只锁定索引记录，而不锁定它们之前的间隙，因此允许自由插入新记录在锁定的记录旁边。间隙锁定仅用于外键约束检查和重复键检查。

恕我直言，只有记录锁就足够了。谁能解释一下 Gap 锁定的场景以及为什么 mysql 会这样做？

来自文档的引用：

Read Committed 是 PostgreSQL 中的默认隔离级别。当事务使用此隔离级别时，SELECT 查询（没有 FOR UPDATE/SHARE 子句）只会看到在查询开始之前提交的数据；它永远不会看到未提交的数据或并发事务在查询执行期间提交的更改。实际上，SELECT 查询会在查询开始运行的那一刻看到数据库的快照。但是，SELECT 确实会看到在其自己的事务中执行的先前更新的影响，即使它们尚未提交。另请注意，如果其他事务在第一个 SELECT 执行期间提交更改，则两个连续的 SELECT 命令可以看到不同的数据，即使它们位于单个事务中。

那么 PostgreSQL 是否看到另一个事务提交的更改？

今天我在PostgreSQL 9.5上发现了一些奇怪的东西。（我不知道这是否是因为测试版。）当我想获取数据时，我会从查询中获取旧的和已删除的数据。VACUUM FULL然后我做，然后我得到正确的数据（这是空的）。

我在这里错过了什么吗？PostgreSQL 返回旧数据的原因可能是什么？

注意：自动真空是ON.