SQL Server предоставляет различные функции и оптимизации для улучшения производительности запросов. Одной из таких функций является возможность создания процедур, скомпилированных нативно. В этой статье мы рассмотрим концепцию процедур, скомпилированных нативно, и обсудим их влияние на планы выполнения.

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

Чтобы продемонстрировать различия в планах выполнения между процедурами, скомпилированными нативно, и обычными процедурами, рассмотрим простой пример. У нас есть две процедуры, “AddressDetails” и “BadAddressDetails”, которые извлекают детали адреса на основе заданного города.

Процедура “AddressDetails” является обычной процедурой, в то время как процедура “BadAddressDetails” включает некоторые ненужные модификации, такие как изменение типа данных параметра с NVARCHAR на VARCHAR. Мы ожидаем, что эти модификации могут повлиять на план выполнения.

Однако, когда мы сравниваем планы выполнения обеих процедур, мы обнаруживаем, что они идентичны. Единственное отличие, которое мы наблюдаем, – это операция CAST в операторе Index Seek для процедуры “BadAddressDetails”, как и ожидалось.

Интересно, что время выполнения двух процедур отличается, когда мы выполняем их с использованием разных механизмов передачи параметров. Предпочтительным механизмом для процедур, скомпилированных нативно, является передача параметров без использования синтаксиса “@parameterName =”. Этот метод приводит к более быстрому выполнению по сравнению с традиционным синтаксисом.

Кроме того, мы замечаем, что время выполнения процедуры “BadAddressDetails” медленнее, чем процедуры “AddressDetails”, даже если план выполнения не указывает на значительные различия. Это расхождение подразумевает, что план выполнения не всегда точно отражает фактическую производительность процедур, скомпилированных нативно.

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

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

В заключение, процедуры, скомпилированные нативно, предлагают значительное улучшение производительности в SQL Server. Однако их планы выполнения не всегда точно отражают их фактическую производительность. Важно экспериментировать и анализировать различные сценарии, чтобы полностью понять поведение процедур, скомпилированных нативно.

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

Спасибо за чтение!