• Другие части статьи:
• 1
• 2
• вперед »

Способы противодействия параметризации.

Итак, как вы уже поняли, сейчас нам предстоит изучить несколько «контр-параметризационных» методик. Обратите внимание, что на них можно смотреть и с обратной стороны — если целевая колонка фильтрации имеет хорошее и равномерное распределение данных, и, как следствие, вы ни разу не против параметризации а очень даже за нее, то вам следует всеми силами избегать упоминаемых далее приемов. Ведь они «рубят» параметризацию не задаваясь вопросом о ее уместности в данных и конкретных обстоятельствах. Так что все как обычно: решение принимаем мы, движок сервера его послушно исполняет.

Применение локальных переменных для передачи значения параметра.

Одним из простейших частично (и это замечание огромной важности, внимательно читайте далее и особое внимание уделяйте ближайшим примерам кода) работающих приемов является передача значения параметра не в виде константного числа/статичной строки символов, а его «обертывание» в переменную и передача в запрос уже ее. Обратимся к примеру автоматической (а не ручной) параметризации:

• Другие части статьи:
• 1
• 2
• вперед »

Итак, блог sqlCMD.ru продолжает цикл публикаций посвященный такой непростой теме, как параметризация запросов. В статье открывающей данный цикл, Параметризация запросов. Ваш лучший друг? мы выяснили что грамотно и к месту примененный данный механизм способен дать выигрыш в итоговой производительности решения столь значительный, что даже подтвержденный сухими цифрами «до» и «после» он все-равно продолжает выглядеть сказочно-невероятным. Были указали и причины такой «сказочности»: анализ запроса, построение нескольких альтернативных планов исполнения для него, выбор из этих возможных кандидатов «лучшего из лучших» — все это чрезвычайно ресурсоемкие задачи, и даже для современных серверов с их мультипроцессорными «фишками». А поэтому пропуск этих задач целиком дает такой прирост в скорости выполнения запроса, какой невозможно обеспечить никаким наращиванием железа (мы, разумеется, говорим о потенциальном увеличении числа/качества CPU сервера; вложения в, допустим, апгрейд дисковой подсистемы помочь именно в вопросах быстрейшей оптимизации запросов не могут никак просто по определению). Так вот чем покупать коробку новых/дополнительных CPU и загружать их работой, выгоднее (с любой точки зрения) не покупать ничего, а воспользоваться работой уже готовой, в смысле результатами такой предварительной работы. Именно так и поступает параметризация, значительно повышая наши (и наших пользователей) шансы взять «готовую работу» из кэша планов (plan cache), вместо осуществления полной и очень трудоемкой цепочки, где первым звеном является запрос на языке T-SQL, а звеном финальным — идеальный (или близкий к таковому) план исполнения, помещаемый, к слову сказать, опять же в тот же самый кэш планов.

• Другие части статьи:
• 1
• 2
• 3
• вперед »

Параметризация ручная, с помощью sp_executesql.

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

Заодно проверьте, что индекс iT1 находится во включенном состоянии:

• Другие части статьи:
• 1
• 2
• 3
• вперед »

Параметризация автоматическая, простая.

Собственно, как было отмечено во вступлении, не менее 90% реальных систем (а более технически корректно будет сказать — баз данных, ибо данная опция устанавливается именно на уровне БД) счастливо пребывают именно в этом состоянии — простой авто-параметризации. Наша тестовая база [~DB~] благодаря строке

в скрипте ее создания так же в данный момент относится к указанной и многочисленной когорте. Как работает процесс параметризации при такой опции мы, по сути, уже видели в вводной части статьи — при наличии возможности литеральная часть текста запроса заменяется параметрами, создается план для этой «переоформленной» версии запроса, а сами литералы (то есть их конкретные значения) остаются только в shell-планах. Характерной же особенностью работы авто-параметризации в этом режиме является тот факт, что с точки зрения оптимизатора обстоятельства благоприятные для ее включения (то есть для реального выполнения процесса параметризации) складываются редко, если не сказать чрезвычайно редко. То есть, если запрос, потенциально могущий быть параметризированным, содержит в своем тексте:

• Другие части статьи:
• 1
• 2
• 3
• вперед »

Добрый день, уважаемые читатели блога sqlCMD.ru. Читая ваши вопросы и отзывы, приходящие в изрядном количестве после каждой новой публикации, автор получает богатый материал по поиску тех SQL-вопросов, которые вполне заслуживают отдельной статьи, если не цикла. Если просьба «описать тему X» повторяется регулярно, и если по ней же систематически задают вопросы слушатели SQL-курсов читаемых тем же автором, сомнений нет — «тема животрепещет», как выражается один из заезженных журналистских штампов. Одну из таких «горячих», с точки зрения автора, тем мы с вами сегодня и разберем. Ну, то есть как — разберем, но ровно наполовину. А все потому, что вопрос параметризации запросов (а речь, как вы уже догадались, пойдет именно о ней) зело обширен, многогранен и полон внутренних противоречий. Сложная в общем тема, чего уж там скрывать. А потому, для лучшего и постепенного восприятия материала будет разумно выбрать формат именно цикла статей, и в начальной стадии (то есть в рамках статьи текущей) рассмотреть «светлые стороны» указанного непростого процесса. Стороны же отрицательные, как и борьба с оными, остаются для будущих статей цикла.