авторДумаю пора привлекать спецов из тех.поддержки!

moris, ASCRUS рассудите нас

Ну вот и у меня наконец-то руки дошли до вашего вопроса.

Значит так - разумеется оптимизатор оценивает при генерации плана стоимости физического и логического IO, с теми коэффициентами, которые были представлены выше.. Однако при оценке логического / физического IO, оптимизатор полагается только на то, что он туда сам и положит на предыдущих шагах выполнения данного запроса..
Например, рассматривает разные стратегии выполнения запроса - то же самое реформатирование - (создание внутренней временной таблицы в tempdb, выполняя физическую запись).. Стоит ли ему его использовать??? Кол-во страниц умножается на соответствующие коеффициенты и получается общая стоимость плана..
Полученный план с реформатированием используя Physical IO, будет ли дешевле, чем энное кол-во раз запрашивать страницы из кеша Logical IO ???

При генерации плана оптимизатор не может оценить, сколько %% нужных страниц там находятся, (если он сам их туда не загонит.. см. выше)

Для того, что неверующих в этом убедить давайте выполним простой тест в ASE15..

dbcc traceon(3604)
go
set option show_pio_costing long -- оценка оптимизатора по физическому IO
go
set option show_lio_costing long -- оценка оптимизатора по логическому IO
go
set statistics io on -- реальный IO (почтитанный после выполнения запроса)
go


select * from PMATTR

FINAL PLAN ( total cost = 2289.5 ):
lio=57 pio=56 cpu=7755

Table: PMATTR scan count 1, logical reads: (regular=56 apf=0 total=56), physical reads: (regular=8 apf=48 total=56), apf IOs used=48


Еще раз выполняем.. Данные таблицы находятся точно в кеше.. Сможет ли оптимизатор при генерации плана увидеть это ??

FINAL PLAN ( total cost = 2289.5 ):
lio=57 pio=56 cpu=7755

Table: PMATTR scan count 1, logical reads: (regular=56 apf=0 total=56), physical reads: (regular=0 apf=0 total=0), apf IOs used=0

Ответ - нет, не видит..