VC>то профайлер показывает ровно то количество чтений страниц у этого select сверху, сколько весит таблица. Вместо нуля.
Физических же чтений (physical reads) имеется ввиду? Это ожидаемо.

VC>Получается при любом select в том числе такой как выше, sql server вычитывает всю таблицу целиком
Если в запросе есть count, то да, приходится читать всю таблицу или индекс.

VC>Есть ли что то типа dbcc что бы это убрать?
Прогони типовые запросы после восстановления из бэкапа. Кэш прогреется, статистика накопится.

VC>При этом для backup сделаны все условия что бы такого не происходило. Бекап полный и ровно один ...
Непонятно, как это должно помочь.

VC>Ну и самое главное. Если будет запрос который некий index seek будет использовать то этот очередной запрос тоже весь индекс вычитает полностью при первом вызове после restore?
Да. Ну а как по другому-то?
Вот у тебя БД, которую только что восстановили из бэкапа.
MSSQL о ней ничего не знает: нет ни страниц в дисковом кэшэ (т.к. операций чтения еще не было), ни какой-либо статистики по запросам.
И его просят посчитать count(1) на таблице.
Как он будет это делать?
Вот если бы count хранился где-то в метаданных таблицы, тогда все было бы просто — прочитали с диска ровно одну страницу с метаданными и достали count.
Но, увы, в MSSQL count так не хранит.
Поэтому, серверу придется последовательно пройтись по всем страницам таблицы (ну или индекса, если он есть и видится более подходящим) и просуммировать количество строк.
Очевидно, что страницы при этом нужно зачитывать с диска (physical reads), т.к. в кэше их еще нет.

VC>Есть ли что то типа dbcc что бы это убрать?
Прогнать типовые запросы после восстановления из бэкапа.
Это прогреет дисковый кэш.

VC>то профайлер показывает ровно то количество чтений страниц у этого select сверху, сколько весит таблица. Вместо нуля.
Физических же чтений (physical reads) имеется ввиду? Это ожидаемо.

VC>Получается при любом select в том числе такой как выше, sql server вычитывает всю таблицу целиком
Если в запросе есть count, то да, приходится читать всю таблицу или индекс.

VC>При этом для backup сделаны все условия что бы такого не происходило. Бекап полный и ровно один ...
Непонятно, как это должно помочь.

VC>Ну и самое главное. Если будет запрос который некий index seek будет использовать то этот очередной запрос тоже весь индекс вычитает полностью при первом вызове после restore?
Да. Ну а как по другому-то?
Вот у тебя БД, которую только что восстановили из бэкапа.
MSSQL о ней ничего не знает: нет ни страниц в дисковом кэшэ (т.к. операций чтения еще не было), ни какой-либо статистики по запросам.
И его просят посчитать count(1) на таблице.
Как он будет это делать?
Вот если бы count хранился где-то в метаданных таблицы, тогда все было бы просто — прочитали с диска ровно одну страницу с метаданными и достали count.
Но, увы, в MSSQL count так не хранит.
Поэтому, серверу придется последовательно пройтись по всем страницам таблицы (ну или индекса, если он есть и видится более подходящим) и просуммировать количество строк.
Очевидно, что страницы при этом нужно зачитывать с диска (physical reads), т.к. в кэше их еще нет.

VC>Есть ли что то типа dbcc что бы это убрать?
Прогнать типовые запросы после восстановления из бэкапа.
Это прогреет дисковый кэш.