Понимание процесса обновления qnd запроса индексированного представления в SQL Server 2008 R2

Question

Я создал индексированное представление (кластеризованный уникальный индекс на Table1_ID) с таким T-SQL:

Select Table1_ID, Count_BIG(*) as Table2TotalCount from Table2 inner join
Table1 inner join... where Table2_DeletedMark=0 AND ... Group BY Table1_ID

Также после создания представления мы устанавливаем кластеризованный уникальный индекс для столбца Table1_ID.
Итак, View состоит из двух столбцов:

Table1_ID
Table2TotalCount

T-Sql для создания View является тяжелым из-за группирования по нескольким миллионам строк в Table2.

Но когда я запускаю запрос к представлению, подобному

Select Total2TotalCount from MyView where Table1_ID = k

- выполняется быстро и без нагрузки на сервер.

Также в t-sql для создания представления много условий в предложении where для Table2 столбцов. А также Если я изменил Table2_DeletedMark на 1 и запустил запрос

Select Total2TotalCount from MyView where Table1_ID = k

снова - я получу правильные результаты. (Table2TotalCount уменьшилось на 1).

Итак, наши вопросы:
1. Почему время выполнения запроса так сильно уменьшилось, когда мы использовали индексированное представление (сравните с использованием без представления (даже мы запускаем DBCC DROPCLEANBUFFERS() перед выполнением запроса к VIEW))
2. После изменения

Table2_DeletedMark 

Просмотр сразу пересчитывается и мы получаем правильные результаты, но каков процесс позади? мы не можем представить, что sql выполняет t-sql в зависимости от того, какое представление генерировалось каждый раз, когда мы изменяем любые значения более 10 столбцов, содержащихся в генерации представления t-sql, потому что оно слишком тяжелое.
Мы понимаем, что достаточно выполнить простой запрос для пересчета значений, в зависимости от значений столбцов, которые мы меняем.
Но как sql это понимает?

Answer 1

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

Столбцы в индексированном представлении могутиндексироваться и некластеризованными индексами, и, таким образом, вы можете еще больше повысить производительность запросов.Обратная сторона: поскольку строки хранятся, вам нужно место на диске (и некоторые данные дублируются, очевидно).

С другой стороны, обычное представление - это просто фрагмент SQL, который будет выполнен для вычислениярезультаты - в зависимости от того, что вы выбираете из этого представления.Там нет физического представления этого представления, нет никаких строк, сохраненных для обычного представления - их необходимо соединять вместе из базовых таблиц по мере необходимости.

Answer 2

Почему, по вашему мнению, существует так много странных правил относительно того, что разрешено в индексированных представлениях, и что разрешено делать базовым таблицам?Это так, что движок SQL может сразу узнать: «Если я коснусь этой строки, это потенциально повлияет на результат этого представления - давайте посмотрим, эта строка больше не соответствует критериям представления, но я настаивал на наличии COUNT_BIG (*),так что я могу просто уменьшить это значение на один "