Автор ссылается на изменение шаблона хранимых процедур по умолчанию с 2000 по 2005 год и предлагает, чтобы "Microsoft даже поняла проблему" , которая вызвала изменение в этом шаблоне.
Есть ли у кого-то серьезные доказательства того, что либо поддерживает, либо опровергает заявленное увеличение производительности при установке NOCOUNT ON.
Последняя ссылка в моем вопросе здесь: "SET NOCOUNT ON use" относится к статью об этом.
Учитывая, насколько это тривиально, почему бы не оставить его и не остановить клиентскую обработку другого набора результатов?
И без SET NOCOUNT ON, nHibernate также может сломаться (упоминается в вопросе)
Существуют сценарии, в которых SET NOCOUNT ON является обязательным. При разработке высокопроизводительного среднего уровня на основе асинхронной обработки с использованием пула потоков с помощью методов SqlClient BeginExecuteXXX существует очень серьезная проблема с подсчетом строк. Методы BeginExecute завершаются, как только сервер ответа первый возвращается сервером. Но когда вызывается EndExecuteXXX, это завершается по запросам без запроса, когда вызов завершен. Каждый ответ rowcount является ответом. При обработке даже умеренно сложных процедур первое количество строк может возвращаться через 5-10 мс, а вызов завершается через 300-500 мс. Вместо того, чтобы отправить запрос асинхронного запроса обратно через 500 мс, он перезванивает через 5 мс, а затем блокирует обратный вызов в EndExecuteXXX за 495 мс. В результате асинхронные вызовы заканчиваются преждевременно и блокируют поток из пула потоков в вызовах EndExecuteNonQuery. Это приводит к голоданию ThreadPool. Я видел, что высокопроизводительные системы повышают пропускную способность сотен вызовов в секунду до тысяч вызовов в секунду, просто добавляя SET NOCOUNT ON по конкретным сценариям.
Учитывая, что для высокоуровневой/высокопроизводительной обработки среднего уровня асинхронные вызовы являются единственным способом, NOCOUNT в значительной степени является обязательным требованием.
Я согласен, что использование NOCOUNT - отличная идея. Это ужасная идея добавить его ко всему коду, выполняемому в каждом операторе SPROC или динамическом SQL.
Особенно, если вы говорите о высокой производительности. TSQL NOCOUNT должен быть установлен по необходимости кодом на уровне доступа к данным. Также как транзакции и уровни блокировки.
Настройка этих вещей каждый раз в исполняемом SQL, который будет выполняться каждый раз, не дает вам большого повышения производительности, которое вы могли бы получить, установив их в код подключающего приложения.
Лучшая производительность достигается путем написания лучшего кода, а не добавления операторов SET NOCOUNT ко всем вашим SQL.