关于 SQL Server 锁定机制

Question

我想请教一些与SQL Server锁定机制相关的问题。

1. 如果我在SQL语句中没有使用锁提示，那么SQL Server默认使用PAGELOCK提示。我是对的吗？如果是，为什么？也许这是由于管理太多锁的因素，这是我认为的唯一的缺点，但如果还有其他原因，请告诉我。并且告诉我如果我们可以改变这种默认行为是否合理。

2. 我正在编写一个服务器端应用程序，一个同步服务器（不使用同步框架），我已经在C#代码文件中编写了数据库查询，并使用ODBC连接来执行它们。现在的问题是，考虑到缺点（例如在查询中添加锁提示），什么是将默认锁从Page更改为Row的最佳方法。

3. 如果在没有事务范围的情况下执行SQL查询（SELECT/DML），并且语句包含锁提示，则会获得什么类型的锁（例如共享、更新、独占）？在事务范围内时，事务的隔离级别是否对使用ROWLOCK提示的锁类型产生影响。

4. 最后，如果有人能给我提供示例，这样我就可以自己测试和体验所有上述情况（例如dot net代码或sql脚本）。

谢谢 Mubashar

- Mubashar

Answer 1

1. 不会。它会根据需要锁定并升级锁定。

2. 让数据库引擎来管理。

3. 见第2点。

4. 见第2点。

只有在需要特定和确定的行为时才使用锁提示，例如队列或非阻塞（脏）读取。

更一般地说，您为什么认为数据库引擎默认情况下不能满足您的需求？

- gbn

Answer 2

默认情况下，锁定方式为行锁而非页锁。虽然锁定机制的运作方式意味着您将在层次结构内的所有对象上放置锁，例如读取单个行会在表上放置共享锁、在页上放置共享锁，然后在行上放置共享锁。

这使得请求对表进行排他锁的操作知道它可能还不能获得锁，因为已存在一个共享锁（否则它将不得不检查每个页面/行的锁）。

但如果对于单个查询发出了太多的锁，则会执行锁升级，从而减少锁的粒度 - 以便管理更少的锁。可以使用跟踪标志关闭此选项，但我认为这并不值得考虑。

在确定确实存在锁定/锁升级问题之前，您冒着过早优化不存在问题的风险。

- Andrew