Интересно, что сам по себе мониторинг статистики тоже может влиять на время.
Год назад читал статью How to Make Scalar UDFs Run Faster (SQL Spackle)
Там был результат измерения времени выполнения запроса со скалярной функций при помощи двух методов:
1) set statistics time
2) datediff
Результаты в статье такие:
statistics timeSQL Server Execution Times:
CPU time = 109031 ms, elapsed time = 299436 ms.

datediff7456


И я тогда отписался там в комментах:
SomewhereSomehowJeff Moden,
Wonderful note about set statistics time! Never heard of it!
Т.е. скорее всего у меня получилось воспроизвести такой результат (хотя может я поверил "наслово" - но я такое редко от себя могу ожидать=)).
Сейчас пытаюсь проиграть конкретно те примеры из статьи - не получается такой драматической разницы во времени выполнения.
Пробовал на голом 2008r2 rtm, 2008r2 sp2, 2012 sp1.

Однако, небольшая, но разница все же есть:

автор SQL Server Execution Times:
CPU time = 1934 ms, elapsed time = 2436 ms.
-------------------------------------
Elapsed time:1940

Т.е. само по себе измерение статистики - тоже может влиять на время =)


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

zxc1257,

Я тоже так подумал сначала и прежде чем постить вопрос - протестил для 10 млн и 100 млн,
у меня получились те же тайминги только в пропорции.
В статье же, уже при 1 млн - какие-то дикие расхождения.
В статье есть даже отдельный раздел: "If you measure it, you change it."
Вот мне и интересно.

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

МуМу,

Насчет сети надобно проверить все равно, идея хорошая! Просто так отключение протокола shared memory ничего не дает, но мало ли там как реализовано...вдруг переключение контекста скалярной функции как-то взаимодействует... Я уже как в анекдоте - никому не верю. Завтра на работе проверю, еще и между доменами и разными сегментами сети потестирую, сейчас чертов удаленный рабочий стол завис.

Но в любом случае - печально то, что сам сбор статистики по времени - влияет на время (даже если и незначительно). Это хотя бы должно быть документировано - в документации я этого не нашел. Может плохо искал.
SET STATISTICS TIME
авторОтображает время в миллисекундах, необходимое для синтаксического анализа, компиляции и выполнения каждой инструкции.
Также, где сказано, что учитывается время передачи клиенту? А оно учитывается!
Может это где-то сказано в других разделах? Но почему не в этом, релевантном?

zxc1257,
МуМу,
Давайте все-таки просто проверим! Спорить нет смысла.

Про сеть - очень хорошее предположение. Вообще, почему скалярные функции работаю так медленно? Потому, что каждый раз при выполнении скалярной функции - есть переключение контекста, как если бы выполнялся отдельный модуль. Я, например, не уверен, что в режиме включенного сбора статистики модуль скалярной функции не взаимодействует с сетью.

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

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