Установить NOCOUNT на использование

Мне потребовалось много копать, чтобы найти реальные контрольные цифры вокруг NOCOUNT, поэтому я решил поделиться быстрым резюме.

• Если хранимая процедура использует курсор для выполнения множества очень быстрых операций без возвращаемых результатов, отключение NOCOUNT может занять примерно в 10 раз больше времени, чем его включение. ¹ это худший сценарий.
• Если хранимая процедура выполняет только одну быструю операцию без возврата результаты, установка NOCOUNT ON даст около 3% повышения производительности. ² это будет соответствовать типичной процедуре вставки или обновления.
• Если хранимая процедура возвращает результаты (т. е. вы выбираете что-то), разница в производительности будет уменьшаться пропорционально размеру результирующего набора.

• когда SET NOCOUNT включен, счетчик (указывающий количество строк, на которые влияет инструкция Transact-SQL) не возвращается. Когда SET NOCOUNT выключен, счетчик возвращается. Он используется с любой операцией SELECT, INSERT, UPDATE, DELETE.

• настройка SET NOCOUNT устанавливается во время выполнения или выполнения, а не во время синтаксического анализа.

• SET NOCOUNT ON улучшает хранимую процедуру (SP) спектакль.

• синтаксис: SET NOCOUNT { ON / OFF }

пример SET NOCOUNT ON:

пример SET NOCOUNT OFF:

Я думаю, в какой-то степени это проблема DBA против разработчика.

как dev в основном, я бы сказал, Не используйте его, если вы абсолютно положительно не должны - потому что использование его может сломать ваш ADO.NET код (как задокументировано Microsoft).

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

кроме того, если ваши разработчики когда-либо использовали "RecordsAffected", возвращаемый ADO.NET s ExecuteNonQuery вызов метода, вы в беде, если все используют SET NOCOUNT ON так как в этом случае ExecuteNonQuery всегда будет возвращать 0.

также смотрите Питера Бромберга блоге и проверьте его положение.

Так что это действительно сводится к тому, кто будет устанавливать стандарты :-)

Марк

Если вы говорите, что у вас могут быть разные клиенты, есть проблемы с классическим ADO, если SET NOCOUNT не установлен.

один я испытываю регулярно: если хранимая процедура выполняет ряд операторов (и, таким образом, возвращается несколько сообщений "xxx строк, затронутых"), ADO, похоже, не обрабатывает это и выдает ошибку " невозможно изменить свойство ActiveConnection объекта набора записей, источником которого является объект Command."

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

рискуя сделать вещи более сложными, я призываю немного другое правило для всех тех, кого я вижу выше:

• всегда ставим NOCOUNT ON в верхней части proc, прежде чем делать какую-либо работу в proc, но и всегда SET NOCOUNT OFF снова, прежде чем вернуться любой набор записей из хранимой тез.Докл.

поэтому "обычно держите nocount, за исключением случаев, когда вы фактически возвращаете resultset". Я не знаю, как это может сломать любой клиентский код, это означает, что клиентский код никогда не должен ничего знать о внутренних процессах proc, и это не особенно обременительно.

Что касается триггеров, разрушающих NHibernate, у меня был этот опыт из первых рук. В принципе, когда NH делает обновление, он ожидает определенное количество затронутых строк. Добавляя SET NOCOUNT в триггеры, вы получаете количество строк обратно к ожидаемому NH, тем самым устраняя проблему. Так что да, я бы определенно рекомендовал отключить его для триггеров, если вы используете NH.

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

на другой ноте, вы должны действительно рассмотреть вопрос о переходе от архитектуры на основе SP, тогда у вас даже не будет этого вопроса.

УСТАНОВИТЬ NOCOUNT НА; Вышеуказанный код остановит сообщение, сгенерированное SQL server engine для переднего окна результата после выполнения команды DML/DDL.

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

Я не знаю, как протестировать SET NOCOUNT между клиентом и SQL, поэтому я тестировал аналогичное поведение для другой команды SET "SET TRANSACTION ISOLATION LEVEL READ UNCIMMITTED"

Я отправил команду из моего соединения, изменив поведение SQL по умолчанию (Read COMMITTED), и она была изменена для следующих команд. Когда я изменил уровень изоляции внутри хранимой процедуры, это не изменило поведение соединения для следующей команды.

текущая заключение

1. Изменение параметров внутри хранимой процедуры не менять настройки по умолчанию подключение.
2. изменение настроек путем отправки команд с помощью ADOCOnnection изменяет поведение по умолчанию.

Я думаю, что это относится к другой команде SET, такой как"SET NOCOUNT ON"

SET NOCOUNT ON;

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

if (set no count== off)

{ затем он будет держать данные о том, сколько записей так уменьшите представление } еще { он не будет отслеживать изменения следовательно, улучшить perfomace } }

Я знаю, это довольно старый вопрос. но только для обновления.

лучший способ использовать "SET NOCOUNT ON" - поместить его в качестве первого оператора в SP и снова отключить его перед последним оператором SELECT.