使用SQL Server选择更新

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

现在我要使用：

SELECT * FROM <tablename> FOR UPDATE

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

我试过了：

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

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

SELECT FOR UPDATE以Oracle，DB2，MySql所知，哪个是正确的提示？

编辑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：

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

机制| 在不同的行块上选择| 在同一行块上选择
----------------------- + -------------------------- ------ + --------------------------
ROWLOCK | 没有 没有
上锁，行锁| 是的 是
xlock，rowlock | 是的 是
重复阅读| 没有 没有
DBCC TRACEON（1211，-1）| 是的 是
行锁，xlock，holdlock | 是的 是
上锁，保持锁| 是的 是
UPDLOCK，READPAST | 没有 没有

我在寻找| 没有 是

最近，我遇到了死锁问题，因为Sql Server锁定的锁超过了必需的锁（页）。您真的不能对此采取任何措施。现在，我们正在捕获死锁异常……我希望我改用Oracle。

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

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

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

CREATE INDEX TBLINDEX ON TBL ( id )

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

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

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

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

试试（上锁，行锁）

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

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

您可以通过一些方法将其视为麻烦的根源。查看查询计划；研究指标；请尝试使用ID为1000000而不是1的SELECT来查看是否仍然阻止了其他进程。

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

ALTER DATABASE yourDbNameHere SET READ_COMMITTED_SNAPSHOT ON;

[编辑：10月14日]

读完这篇文章之后：Oracle中比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;

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

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

创建一个伪造的更新以强制执行行锁。

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

如果那没有锁住你的行，上帝知道会怎样。

之后，UPDATE您就可以SELECT (ROWLOCK)进行更新了。

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

在使用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

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

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

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

因此，如果打算长时间“检出”某行，而不是事务锁定，则最好使用具有值的列和简单的ol'update语句将行标记为已锁定或未锁定。

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

尝试使用：

SELECT * FROM <tablename> WITH ROWLOCK XLOCK HOLDLOCK

这应该使锁排他并在事务期间保持它。

根据本文，解决方案是使用WITH（REPEATABLEREAD）提示。

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

MSSQL通常将这些行锁升级为页面级锁（甚至表级锁，如果您在查询的字段上没有索引），请参见以下说明。由于您要求进行更新，因此我可以假设您需要事务级别（例如财务，库存等）的鲁棒性。因此，该网站上的建议不适用于您的问题。这只是MSSQL升级锁的原因之一。

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

聚苯乙烯
我使用PostgreSQL，它也使用MVCC有更新，我没有遇到同样的问题。锁升级是MVCC解决的问题，因此，如果MSSQL 2005仍使用不包含其字段索引的WHERE子句升级表上的锁，我将感到惊讶。如果对于MSSQL 2005仍然（锁定升级），请尝试检查WHERE子句上的字段是否具有索引。

免责声明：我最后一次使用MSSQL仅是2000版。

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

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

您是否尝试过READPAST？

将表当作队列使用时，我一起使用了UPDLOCK和READPAST。

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

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

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

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