Есть ли снижение производительности для триггера без кода?

Question

В таблице есть триггер для обновлений, вставок и удалений, но сценарий создания T-SQL для триггера содержит только следующий оператор:

SET NOCOUNT ON

Есть ли (значительное) снижение производительности для этого триггера по сравнению с отсутствием триггера? Будет ли какое-либо (значительное) снижение производительности для триггера без операторов (кода), опять же по сравнению с отсутствием триггера вообще?

Answer 1

Без глубокого знания того, что делает оптимизатор, или запуска множества тестов, чтобы проверить, трудно сказать. Но тогда трудно сказать, насколько значительным является ваше представление о значительном.

Итак, чтобы принять все крайние меры, если вы делаете тысячи обновлений в секунду, то триггер может привести к значительному падению производительности ... С другой стороны, при запуске нескольких обновлений в минуту вы, вероятно, вообще не заметите. В любом случае триггер будет скомпилирован и, возможно, оптимизирован из-за отсутствия.

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

В том же духе у меня был администратор базы данных, предложивший заменить Coalesce (xyz, 0) на Isnull (xyz, 0). Запрос меня не беспокоил, но предложение помогло, поэтому я провел некоторые измерения и обнаружил, что он действительно на 30% быстрее. Но при 0,00000031 для каждого из двух объединенных вызовов в моем запросе я не изменил свой запрос; -

Answer 2

Этот оператор предотвращает передачу дополнительных сообщений вызывающей стороне.

Представьте, что в вашем триггере есть 5 операторов обновления.Если у вас не было строки NOCOUNT, вызывающий абонент получит сообщения от всех 5 операторов.Примерно так: (затронуто 1 рядов) (затронуто 1 рядов) (затронуто 1 рядов) (затронуто 1 ряд) (затронуто 1 ряд)

Если у вас установлен оператор NOCOUNT, он получит только сообщение о конечном результате: (затронут 1 строка)

Это не обязательно плохо - некоторые системы не заботятся о дополнительныхсообщений, и, возможно, ваша база данных не настолько велика, чтобы вас беспокоило любое снижение производительности.Хотя некоторые другие системы заботятся - я знаю, что должен помнить об использовании NOCOUNT в хранимых процедурах, которые вызываются из служб Reporting Services (SSRS).