查询返回的结果大于 5000 条记录时 SQL 是否锁定表？答案

【问题标题】：Does SQL lock tables when queries return results greater than 5000 records?查询返回的结果大于 5000 条记录时 SQL 是否锁定表？
【发布时间】：2019-04-17 01:04:14
【问题描述】：

我在 SharePoint 中工作，并试图了解为什么列表上的视图数量限制为 5000 条记录。

我的问题不是关于 SharePoint，而是关于 SQL。 SQL 是否具有下述限制，或者这是 SharePoint 团队强加给 SQL 的限制？

出于性能原因，每当 SQL Server 执行单个查询时返回 5000 + 项，锁升级发生在 SQL 桌子。结果，整个表将被锁定。由于整个 Share Point 数据存储为单个表，单个列表视图查询超过 5000+ 项将锁定整个 Share Point 数据表在那个内容中。数据库和所有用户将面临巨大的性能下降。使用 Share Point 的整个用户集锁升级的时间将不得不等待更长的时间检索数据。因此，您可以看到列表阈值是后端 SQL Server 对 Share Point 施加的限制。这个问题是由SQL产生的，原因是行锁升级。为了避免这种性能下降，分享 Point 已经限制了 5000 条在任何时候可以查询时间点。任何超过 5000 个项目的查询都将被处理阈值错误信息。参考链接

谢谢

编辑____________________________________

关于这个问题的文章： https://www.c-sharpcorner.com/article/sharepoint-list-threshold-issue-the-traditional-problem/

【问题讨论】：

嗨，我的研究是 Sharepoint 限制，而不是 sql server 限制，请参阅此链接：docs.microsoft.com/fr-fr/previous-versions/office/…
如果您链接到该引用的来源可能会有所帮助（如果没有其他原因，则出于归因原因）。据我所知，MS 没有记录特定断点编号。
其他链接可以帮助你：support.office.com/en-us/article/…
长话短说，太宽的查询会导致大量扫描，从而严重降低多用户 DMS 的性能。最终用户也不可能查看 5000 个项目，除非有人尝试将 List 当作表格使用。在这种情况下，指定正确的索引至关重要
SQL Server 可能会在单个对象引用上持有 5,000 个锁后尝试锁升级。请参阅Escalation Threshold for a Transact-SQL Statement 但除非以高于通常的隔离级别运行，否则不会在读取 5,000 个项目之后。您需要行锁定和至少可重复读取才能像这样关联项目和锁。读取时，一旦读取数据，就会释放已提交的锁

标签： sql-server sharepoint

【解决方案1】：

当查询返回的结果大于 5000 时，SQL Server 是否锁定表记录？

一般不会，不会。

is documented 5,000 是数据库引擎第一次尝试锁升级（随后以 1,250 增量进一步尝试）的幻数，但除非以可重复读取或可序列化隔离级别运行，否则通常不会仅通过返回来命中SELECT 中有 5,0000 个项目。默认读取提交级别将在读取数据后立即释放锁，因此永远不会达到阈值。

您可以通过以下示例看到隔离级别对此的影响。

CREATE TABLE T(C INT PRIMARY KEY);

INSERT INTO T 
SELECT TOP 10000 ROW_NUMBER() OVER (ORDER BY @@SPID)
FROM sys.all_objects o1, sys.all_objects o2

And（使用未记录的跟踪标志，因此只能在开发环境中使用）

DBCC TRACEON(3604,611);

/*5,000 key locks are held*/
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN TRAN
SELECT COUNT(*) FROM (SELECT TOP 5000  C FROM T) T
SELECT resource_type, request_mode, count(*) FROM sys.dm_tran_locks where request_session_id = @@spid GROUP BY resource_type, request_mode;
COMMIT


/*No key locks are held. They have been escalated to an object level lock. The messages tab shows the lock escalation (in my case after 6248 locks not 5,000)*/
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN TRAN
SELECT COUNT(*) FROM (SELECT TOP 10000  C FROM T) T
SELECT resource_type, request_mode, count(*) FROM sys.dm_tran_locks where request_session_id = @@spid GROUP BY resource_type, request_mode;
COMMIT


/*No key locks are held. They are released straight away at this isolation level. The messages tab shows no lock escalation messages*/
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN TRAN
SELECT COUNT(*) FROM (SELECT TOP 10000  C FROM T) T
SELECT * FROM sys.dm_tran_locks where request_session_id = @@spid 
COMMIT


DBCC TRACEOFF(3604,611);

【讨论】：