Оптимизация производительности sql-сервера путем удаления операторов печати

Question

Мы проходим раунд оптимизации хранимых процедур sql-сервера. Одна рекомендация, которую мы нашли, которая явно применима к нам, это «УСТАНОВИТЬ NOCOUNT ON» вверху каждой процедуры. (Да, я видел сообщения, которые указывают на проблемы с этим в зависимости от того, с каких клиентских объектов вы запускаете хранимые процедуры, но для нас это не проблемы.)

Так что теперь я просто пытаюсь добавить немного здравого смысла. Если преимущество SET NOCOUNT ON заключается в простом уменьшении сетевого трафика каждый раз на небольшую величину, разве не имеет смысла отключать все операторы PRINT, которые есть в хранимых процедурах, которые мы используем только для отладки?

Я не вижу, как это может повредить производительности. OTOH, это немного хлопотно для реализации из-за того, что некоторые операторы print являются единственными в предложениях else, так что вы не можете просто всегда закомментировать одну строку и все готово. Изменения несут определенную степень риска, поэтому я не хочу делать это, если это не поможет.

Но я не вижу исключения упоминаний о печати в статьях по оптимизации. Это потому, что это так очевидно, что никто не потрудился упомянуть об этом?

Answer 1

У меня была проблема с большими объемами диагностических данных, которые были напечатаны в сохраненном процессе, что вызвало ошибку при вызове из ADO.NET (ошибки при прямом вызове нет). К сожалению, я не могу вспомнить ошибку, но я добавил флаг, чтобы диагностические сообщения были обернуты в условные выражения, чтобы избежать их отправки в производство.

Answer 2

Если вы вызываете PRINT внутри цикла (например, печать при разрезании строк), тогда да, вы можете сэкономить время, и это может быть весьма значительным, если вы просматриваете достаточно записей.Если не считать того, что если сами ваши хранимые процедуры не будут повторяться в цикле, я бы лично оставил там операторы PRINT.Их производительность для небольших струн, как правило, должна быть незначительной.