使用 SQL Server 选择更新

Question

我正在使用隔离级别为READ_COMMITTED 和READ_COMMITTED_SNAPSHOT=ON 的Microsoft SQL Server 2005 数据库。

现在我想使用：

SELECT * FROM <tablename> FOR UPDATE

...以便其他数据库连接在尝试访问同一行“FOR UPDATE”时阻塞。

我试过了：

SELECT * FROM <tablename> WITH (updlock) WHERE id=1

...但这会阻止所有其他连接，即使选择“1”以外的 id。

对于 Oracle、DB2、MySql，执行 SELECT FOR UPDATE 的正确提示是什么？

编辑 2009-10-03：

这些是创建表和索引的语句：

CREATE TABLE example ( Id BIGINT NOT NULL, TransactionId BIGINT, 
    Terminal BIGINT, Status SMALLINT );
ALTER TABLE example ADD CONSTRAINT index108 PRIMARY KEY ( Id )
CREATE INDEX I108_FkTerminal ON example ( Terminal )
CREATE INDEX I108_Key ON example ( TransactionId )

很多并行进程都这样做SELECT：

SELECT * FROM example o WITH (updlock) WHERE o.TransactionId = ?

编辑 2009-10-05：

为了更好地了解我在下表中记录了所有尝试过的解决方案：

机制 |在不同的行块上选择 |在同一行块上选择 ------------------------------------+-------------- ------+-------------- 行锁 |没有 |不 更新锁、行锁 |是的 |是的 xlock,rowlock |是的 |是的 可重复阅读 |没有 |不 DBCC TRACEON (1211,-1) |是的 |是的 行锁，xlock，holdlock |是的 |是的 上锁，挂锁| 高分辨率照片| CLIPARTO是的 |是的 上锁，阅读过去 |没有 |不 我在寻找 |没有 |是的

Answer 1

最近我有一个deadlock problem，因为 Sql Server 锁定的次数超过了必要的次数（页面）。你真的不能对它做任何事情。现在我们正在捕获死锁异常......我希望我有 Oracle。

编辑： 我们同时使用快照隔离，它解决了很多但不是全部的问题。不幸的是，为了能够使用快照隔离，它必须得到数据库服务器的允许，这可能会在客户站点造成不必要的问题。现在我们不仅要捕获死锁异常（当然，这仍然可能发生），而且还要捕获并发问题以从后台进程重复事务（用户不能重复）。但这仍然比以前好很多。

Answer 2

我有类似的问题，我只想锁定 1 行。 据我所知，使用UPDLOCK 选项，SQLSERVER 会锁定它需要读取的所有行以获取该行。因此，如果您没有定义直接访问该行的索引，则所有前面的行都将被锁定。 在您的示例中：

假设您有一个名为 TBL 的表，其中包含 id 字段。 您想用id=10 锁定行。 您需要为字段 id（或您选择的任何其他字段）定义索引：

CREATE INDEX TBLINDEX ON TBL ( id )

然后，您只锁定您读取的行的查询是：

SELECT * FROM TBL WITH (UPDLOCK, INDEX(TBLINDEX)) WHERE id=10.

如果不使用 INDEX(TBLINDEX) 选项，SQLSERVER 需要从表的开头读取所有行以找到您的带有id=10 的行，因此这些行将被锁定。

Answer 3

也许使 mvcc 永久化可以解决它（与仅特定批次相反：SET TRANSACTION ISOLATION LEVEL SNAPSHOT）：

ALTER DATABASE yourDbNameHere SET READ_COMMITTED_SNAPSHOT ON;

[编辑：10 月 14 日]

阅读后：Better concurrency in Oracle than SQL Server? 和此：http://msdn.microsoft.com/en-us/library/ms175095.aspx

当 READ_COMMITTED_SNAPSHOT 数据库选项设置为 ON，则 用于支持该选项的机制 立即激活。什么时候 设置 READ_COMMITTED_SNAPSHOT 选项，仅执行连接 允许使用 ALTER DATABASE 命令 在数据库中。必须没有 数据库中其他打开的连接 直到 ALTER DATABASE 完成。这 数据库不必在 单用户模式。

我得出的结论是，您需要设置两个标志才能在给定数据库上永久激活 mssql 的 MVCC：

ALTER DATABASE yourDbNameHere SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE yourDbNameHere SET READ_COMMITTED_SNAPSHOT ON;

Answer 4

先尝试对此行进行简单更新（不真正更改任何数据）如何？之后，您可以继续选择 in 中的行进行更新。

UPDATE dbo.Customer SET FieldForLock = FieldForLock WHERE CustomerID = @CustomerID
/* do whatever you want */

编辑：您当然应该将其包装在事务中

编辑 2：另一种解决方案是使用 SERIALIZABLE 隔离级别

Answer 5

创建一个虚假更新来强制执行行锁。

UPDATE <tablename> (ROWLOCK) SET <somecolumn> = <somecolumn> WHERE id=1

如果这没有锁定你的行，天知道会发生什么。

在此“UPDATE”之后，您可以进行SELECT (ROWLOCK) 和后续更新。

Answer 6

我以完全不同的方式解决了行锁问题。我意识到 sql server 无法以令人满意的方式管理这样的锁。我选择从编程的角度通过使用互斥锁来解决这个问题...waitForLock...releaseLock...

Answer 7

应用程序锁定是一种使用自定义粒度滚动您自己的锁定同时避免“有用”锁定升级的方法。见sp_getapplock。

Answer 8

问题 - 这种情况是否被证明是锁升级的结果（即，如果您使用探查器跟踪锁升级事件，那肯定是发生了什么导致阻塞）？如果是这样，有一个完整的解释和一个（相当极端的）解决方法，通过在实例级别启用跟踪标志来防止锁升级。见http://support.microsoft.com/kb/323630跟踪标志1211

但是，这可能会产生意想不到的副作用。

如果您有意锁定一行并使其锁定较长时间，那么对事务使用内部锁定机制并不是最好的方法（至少在 SQL Server 中）。 SQL Server 中的所有优化都是针对短事务的——进入、更新、退出。这首先是锁升级的原因。

因此，如果打算长时间“签出”一行，而不是事务锁定，最好使用具有值的列和普通的更新语句来将行标记为锁定与否。

Answer 9

我假设您不希望任何其他会话能够在此特定查询运行时读取该行...

使用 WITH (XLOCK,READPAST) 锁定提示将您的 SELECT 包装在事务中将获得您想要的结果。只要确保那些其他并发读取没有使用 WITH (NOLOCK)。 READPAST 允许其他会话在其他行上执行相同的 SELECT。

BEGIN TRAN
  SELECT *
  FROM <tablename> WITH (XLOCK,READPAST) 
  WHERE RowId = @SomeId

  -- Do SOMETHING

  UPDATE <tablename>
  SET <column>=@somevalue
  WHERE RowId=@SomeId
COMMIT

Answer 10

您必须在提交时处理异常并重复事务。

Answer 11

好的，默认情况下，单个选择将使用“已提交读”事务隔离，该隔离会锁定并因此停止对该集合的写入。您可以使用

更改事务隔离级别

Set Transaction Isolation Level { Read Uncommitted | Read Committed | Repeatable Read | Serializable }
Begin Tran
  Select ...
Commit Tran

这些在 SQL Server BOL 中有详细解释

您的下一个问题是，默认情况下，如果您有超过 ~2500 个锁或在锁事务中使用超过 40% 的“正常”内存，SQL Server 2K5 将升级锁。升级到页面，然后是表锁定

您可以通过设置“跟踪标志”1211t 来关闭此升级，有关详细信息，请参阅 BOL

Answer 12

你试过 READPAST 吗？

在将表视为队列时，我将 UPDLOCK 和 READPAST 一起使用。

Answer 13

重新访问您的所有查询，也许您有一些查询在没有 ROWLOCK/FOR UPDATE 提示的情况下从您有 SELECT FOR UPDATE 的同一个表中选择。

MSSQL 经常将这些行锁升级为页级锁（即使是表级锁，如果您正在查询的字段上没有索引），请参阅explanation。由于您要求更新，我可以假设您需要交易级别（例如财务、库存等）的稳健性。因此，该网站上的建议不适用于您的问题。这只是一个洞察为什么 MSSQL 升级锁。

如果您已经在使用 MSSQL 2005（及更高版本），它们是基于 MVCC 的，我认为使用 ROWLOCK/UPDLOCK 提示的行级锁定应该没有问题。但是，如果您已经在使用 MSSQL 2005 及更高版本，请尝试通过检查 WHERE 子句中的字段（如果它们有索引）来检查您的一些查询，这些查询查询您想要 FOR UPDATE 的同一个表是否升级锁。

附言
我正在使用 PostgreSQL，它也使用 MVCC 有 FOR UPDATE，我没有遇到同样的问题。锁升级是 MVCC 解决的问题，所以如果 MSSQL 2005 仍然使用在其字段上没有索引的 WHERE 子句升级表上的锁，我会感到惊讶。如果 MSSQL 2005 仍然存在这种情况（锁升级），请尝试检查 WHERE 子句中的字段是否有索引。

免责声明：我上次使用的 MSSQL 是 2000 版。

Answer 14

根据this article，解决方法是使用 WITH(REPEATABLEREAD) 提示。

Answer 15

您不能同时进行快照隔离和阻塞读取。快照隔离的目的是防止阻塞读取。

Answer 16

尝试使用：

SELECT * FROM <tablename> WITH ROWLOCK XLOCK HOLDLOCK

这应该使锁独占并在事务期间保持它。

Answer 17

完整的答案可以深入研究 DBMS 的内部结构。这取决于查询引擎（执行由 SQL 优化器生成的查询计划）的运行方式。

但是，一种可能的解释（至少适用于某些 DBMS 的某些版本 - 不一定适用于 MS SQL Server）是 ID 列上没有索引，因此任何尝试使用 'WHERE id = ? 进行查询的进程' 最终对表进行顺序扫描，并且该顺序扫描会命中您的进程应用的锁。如果 DBMS 默认应用页级锁定，您也可能会遇到问题；锁定一行会锁定整个页面以及该页面上的所有行。

有一些方法可以揭穿这是麻烦的根源。查看查询计划；研究指标；尝试使用 ID 为 1000000 而不是 1 的 SELECT 并查看其他进程是否仍被阻止。

Answer 18

尝试（updlock，rowlock）