Действительно ли SET NOCOUNT ON так сильно влияет на производительность?

Question

В этой статье автор предполагает, что с SET NOCOUNT ON связаны материальные затраты и что "удаление этих дополнительных издержек из сети может значительно повысить общую производительность вашей базы данных и приложения"

Автор ссылается на изменение шаблона хранимой процедуры по умолчанию с 2000 на 2005 г. и предполагает, что «Microsoft даже осознала проблему», которая вызвала изменение в этом шаблоне.

Есть ли у кого-нибудь убедительные доказательства того, что он поддерживает или опровергает заявленное увеличение производительности, установив NOCOUNT ON.

Answer 1

Существуют сценарии, в которых SET NOCOUNT ON является обязательным. При разработке высокопроизводительного промежуточного уровня на основе асинхронной обработки с использованием пула потоков с помощью методов BeginExecuteXXX SqlClient возникает очень серьезная проблема с количеством строк. Методы BeginExecute завершаются, как только сервер возвращает первый ответный пакет first . Но когда вызывается EndExecuteXXX, это завершается для запросов, не являющихся запросами, когда вызов завершен. Каждый ответ на количество строк является ответом. При обработке даже умеренно сложных процедур число первых строк может вернуться через 5-10 мс, а вызов завершится через 300-500 мс. Вместо передачи обратного асинхронного запроса через 500 мс, он перезванивается через 5 мс, а затем блокирует обратный вызов в EndExecuteXXX в течение 495 мс. В результате асинхронные вызовы завершаются преждевременно и блокируют поток из пула потоков в вызовах EndExecuteNonQuery. Это приводит к истощению ThreadPool. Я видел, как высокопроизводительные системы повышали пропускную способность от сотен вызовов в секунду до тысяч вызовов в секунду, просто добавив SET NOCOUNT ON в определенных сценариях.

Учитывая, что для обработки среднего уровня с высокой пропускной способностью и высокой пропускной способностью асинхронные вызовы являются единственным выходом, NOCOUNT является в значительной степени обязательным требованием.

Answer 2

Последняя ссылка в моем вопросе здесь: " SET NOCOUNT ON use " относится к статье .

Учитывая, насколько это тривиально, почему бы не оставить это и не остановить клиент, обрабатывающий другой набор результатов?

И без SET NOCOUNT ON nHibernate может тоже сломаться (упомянуто в вопросе)

Answer 3

Я согласен, что использование NOCOUNT - отличная идея. Это ужасная идея - добавить его ко всему коду, выполняемому в каждом операторе SPROC или динамическом SQL.

Особенно, если вы говорите о высокой производительности. TSQL NOCOUNT должен быть установлен в соответствии с требованиями кода на уровне доступа к данным. Так же, как транзакции и уровни блокировки.

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

Повышение производительности достигается за счет написания лучшего кода, а не добавления операторов SET NOCOUNT ко всему вашему SQL.