По каким причинам вы бы НЕ выбрали принудительную параметризацию вместо простой параметризации для специальных запросов в SQL Server?
Есть ли накладные расходы на производительность? Если да, то не будет ли это компенсировано (возможным) выигрышем от повторного использования планов запросов?
Вы проанализировали свой кэш планов, чтобы увидеть, есть ли у вас большое количество одноразовых планов?
SELECT usecounts, COUNT(*), SUM(size_in_bytes)
FROM sys.dm_exec_cached_plans
GROUP BY usecounts
ORDER BY usecounts;
Рассматривали ли вы параметр «оптимизировать для специальных рабочих нагрузок', который при по крайней мере, хранит заглушку для плана только до тех пор, пока она не будет использована более одного раза? Я нашел это довольно эффективным.
Если у вас много нерегламентированного SQL и вы наблюдаете раздувание кеша планов, не помешает попробовать принудительную параметризацию. Но вам следует тщательно протестировать всю рабочую нагрузку, поскольку бывают случаи, когда накладные расходы могут перевешивать выгоды (в частности, если вы интенсивно используете индексированные представления, сохраняемые вычисляемые столбцы или секционирование, которое может закончиться худшие планы). Важно отметить, что когда вы включаете этот параметр, он также запускает DBCC FREEPROCCACHE для вас, поэтому ожидайте небольшой сбой, когда все ваши существующие планы необходимо будет перекомпилировать в следующий раз, когда они потребуются. (Конечно, это имеет гораздо менее заметное влияние в случае, когда у вас уже есть «оптимизация для ad hoc» в сочетании с множеством одноразовых планов, поскольку вы в основном удаляете заглушки, которые, вероятно, все равно будут очищены перед повторным использованием.)
Также обратите внимание, что во многих случаях этот параметр не влияет на отдельные запросы (см. раздел Книги в Интернете).
