TaPaKMindпропущено...
Заглулил, молодец! То есть настолько не уверен в своих знаниях или умениях объяснять что пришлось гуглить? И то что я сказал абсолютно тоже самое но своими словами тоже сложно было понять?
где там про "средние"Ты понимаешь хоть то что там написано или просто скопировал? У тебя в статистических данных 200 строк со значениями, как ты будешь их использовать? Все сразу?
Вот у тебя известно что в таблице есть:
1 значение 100
5 значений 200
20 значений 300
WHERE id = @id OPTIMIZE FOR UNKNOWN сколько строк вернет согласно оценке оптимизатора?

Наконец то. А столько пафоса было: "как разберешься - приходи". А в чем разница между "по переданным переменным" и "с проброшенным значением"?
TaPaKсогласно этому хинту актуальный план будет всегда учитывать значение статистики по переданным переменным , а на столбить ваши 20 строк или сколько вы там себе нафаназировали.
Recompile же будет принудительно перекомпилировать запрос с проброшенным значением.Так все таки, переданные переменные будут учитываться или нет? Потому что в твоей цитате из документации сказано прямо противоположное:
TaPaKInstructs the query optimizer to use statistical data instead of the initial values for all local variablesВообще конечно тот кто писал документацию мягко говоря очень далек от SQL Server-а, потому что написал он полную чушь.

Во-первых, о каких local variables идет речь если учитывать что для локальных переменных никакого parameter sniffing нет и быть не может, сервер по-дефолту не знает значения локальных переменных и это опция оптимизатора вообще тут не имеет никакого эффекта.
Во-вторых "use statistical data" - то есть если не указать FOR UNKNOWN то оптимизатор не будет использовать "statistical data"? Что за бред вообще.
Мне потому и смешно что ты процитировал это запутанное и по сути безсмысленное определение и не смог даже нормально перевести его.

OPTIMIZE FOR UNKNOWN - или по сути оптимизация под неизвестное значение так и называется, потому что не важно видит оптимизатор значения параметров/переменных или нет, все равно мы ему говорим оптимизируй запрос так как будто для тебя эти значения неизвестны (UNKNOWN). Ну или еще более упрощенно - оптимизируй запрос так как если бы все параметры были переменными, для которых как мы знаем "просмотр значений" не работает по умолчанию. Именно поэтому, до существования такой опции можно было переназначить параметры локальным переменным и использовать уже их в запросе, и это приводило по сути к тому же эффекту.


Ну а теперь самое интересное, вопрос на который ты не смог ответить, о том как сервер использует статистику для оценочного определения количества строк. Неужели даже интересно не было? Тест накидать за 2 минуты и самому проверить? Для саморазвития так сказать? Нет, зачем же. Гениям это не надо.


Результат:
StmtText EstimateRowsDECLARE @id int = 100 NULLSELECT * FROM dbo.T WHERE id = @id OPTION(OPTIMIZE FOR UNKNOWN) 8.666667 |--Table Scan(OBJECT:([master].[dbo].[T]) WHERE:([master].[dbo].[T].[id]=[@id])) 8.666667
Откуда же берутся эти 8.67? Из статистики:

RANGE_HI_KEY RANGE_ROWS EQ_ROWS DISTINCT_RANGE_ROWS AVG_RANGE_ROWS100 0 1 0 1200 0 5 0 1300 0 20 0 1
(1+5+20)/3=8.66667
TaPaKгде там про "средние"Это называется среднее арифметическое. Урок «Среднее арифметическое чисел», 5 класс


P.S. Не забудь запатентовать что опция OPTIMIZE FOR UNKNOWN ускоряет работу дисков в 5 раз.