Новая официальная документация о принудительной параметризации (Forced Parameterization)

Автор: Brent Ozar, New Official Documentation on Forced Parameterization

Я обожаю хорошую документацию.

Много лет я указывал людям на документацию SQL Server 2008 о принудительной параметризации (Forced Parameterization) — действительно полезном инструменте для уменьшения раздувания кэша планов, получения более точных переиспользуемых планов запросов и включения функций интеллектуальной обработки запросов (Intelligent Query Processing) SQL Server 2019 и 2022, многие из которых полагаются на один и тот же текст запроса, поступающий повторно с течением времени, чтобы настроить его. Однако эта документация была довольно скудной.

Хорошие новости! Появился новый набор документации по принудительной параметризации, который более подробно рассматривает:

• Какие литералы преобразуются в параметры
• Исключения: вещи, которые, казалось бы, должны преобразовываться, но не будут, и это остановит параметризацию всего оператора (statement)
• Исключения частичной параметризации: вещи, которые не будут преобразованы, но остальная часть запроса всё равно будет параметризована, что приведёт к тому, что кэш планов продолжит представлять собой «полную неразбериху» (hot mess) и помешает работе функций Intelligent Query Processing на этих запросах

Там также есть зловещее предупреждение:

Note Parameter names are arbitrary. Users or applications should not rely on a particular naming order. Also, the following can change between versions of SQL Server and cumulative update (CU) upgrades: Parameter names, the choice of literals that are parameterized, and the spacing in the parameterized text.

Имена параметров произвольны. Пользователи или приложения не должны опираться на какой-либо конкретный порядок именования. Кроме того, следующие аспекты могут изменяться между версиями SQL Server и накопительными обновлениями (CU): имена параметров, выбор параметризуемых литералов и интервалов в параметризованном тексте.

На первый взгляд это звучит вполне разумно, но это несёт скрытый смысл. Если вы используете Хранилище запросов (Query Store) и ожидаете, что принудительно применённый запрос останется неизменным от одного накопительного обновления к другому или от версии к версии, он может измениться. Я лично никогда не видел, чтобы эти вещи менялись, но Microsoft говорит, что они могут измениться, что является ещё одним напоминанием о том, что принудительные планы запросов могут перестать быть принудительными после подобного изменения. Возможно, это всегда было и в старой документации — я просто никогда этого не замечал. Тем не менее, мне это кажется разумным. Я бы хотел видеть больше инвестиций в принудительную параметризацию.

Кстати, технически у нас больше нет пакетов обновления (Service Packs), поэтому я, как добросовестный участник сообщества, отправил запрос на изменение (pull request), чтобы заменить это слово на «накопительные обновления» (Cumulative Updates). Напоминаю: когда вы видите опечатку или устаревший язык в документации, вы можете нажать на значок с тремя точками в правом верхнем углу, затем нажать «Править» (Edit), и вас перебросит на Github, где вы сможете отредактировать и отправить запрос на изменение.

Если вы никогда раньше не пользовались Github, поначалу процесс пугает, но как только вы привыкнете, это проще пареной репы, и вы можете отправить правку менее чем за 30 секунд.