Блокирует ли SQL таблицы, когда запросы возвращают результаты, превышающие 5000 записей?

Question

Я работаю в SharePoint и пытаюсь понять, почему существует ограничение в 5000 записей для представлений в списках, которые могут иметь гораздо большее число.

Мой вопрос не о SharePoint, а о SQL. Имеет ли SQL ограничение, описанное ниже, или команда SharePoint наложила это на SQL?

По соображениям производительности всякий раз, когда SQL Server выполняет один запрос который возвращает более 5000 элементов, эскалация блокировок происходит в SQL Таблица. В результате вся таблица будет заблокирована. Так как весь Данные Share Point хранятся в виде одной таблицы, один запрос представления списка более 5000 элементов заблокирует всю таблицу данных Share Point в этом контенте. База данных и все пользователи столкнутся с огромным снижение производительности. Весь набор пользователей, использующих Share Point на время эскалации блокировки придется ждать дольше получить данные. Следовательно, вы можете видеть, что порог списка ограничение, налагаемое на Share Point его внутренним SQL-сервером. Эта проблема возникает из SQL, и причина в блокировке строки эскалация. Чтобы избежать снижения производительности, поделитесь Точка наложила ограничение на 5000 пунктов для запроса в любой точка времени. Любые запросы для 5000+ предметов будут обработаны порог сообщение об ошибке. Ссылка

Спасибо

EDIT ____________________________________

Статья по этому вопросу: https://www.c -sharpcorner.com / статьи / SharePoint-лист порог-эмиссионный-традиционный вопрос /

Answer 1

Блокирует ли SQL Server таблицы, когда запросы возвращают результаты, превышающие 5000 записей?

Обычно нет.

* задокументировано , что 5000 - это магическое число для механизма базы данных, который сначала пытается увеличить блокировку (с последующими дальнейшими попытками с 1250 приращениями), но если только он не работает с повторяющимся уровнем чтения или сериализуемым уровнем изоляции, этокак правило, не ударится, просто вернув 5,0000 предметов за SELECT.Уровень фиксации чтения по умолчанию снимет блокировки, как только данные будут прочитаны, поэтому никогда не достигните порогового значения.

Влияние уровня изоляции можно увидеть в следующем примере.

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

И (использует недокументированные флаги трассировки, поэтому следует использовать только в среде разработки)

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);