Как создать кластерные индексы в представлении в SQL Server 2008. Просмотр не является реальной таблицей, поэтому нет смысла в физическом размещении данных, которые сгруппированы индекс создает.Как создать кластерный индекс для представления
Где я пропущу пункт?
Это несколько упрощенное объяснение. Там есть много технических увлечений, но это звучало так, как будто вы хотели получить общее объяснение «wassup».
Вид, по существу, предварительно написанный и сохраненный запрос; всякий раз, когда вы получаете доступ к представлению, вы извлекаете и подключаете этот предварительно написанный запрос к текущему запросу. (В лучшем случае так я об этом думаю.)
Таким образом, эти «основные» виды считывают данные, хранящиеся в таблицах, уже присутствующих в базе данных/на жестком диске. Когда вы создаете кластерный индекс в представлении, то, что вы действительно делаете, это сделать вторую физическую копию данных, на которые ссылается представление. Например, если у вас есть таблица A, создайте view vA как «select * from A», а затем создайте кластерный индекс в этом представлении, то, что у вас получается, - это две копии данных на жестком диске.
Это может быть полезно, если таблица A очень большая, и вы хотите получить быстрый доступ к небольшому подмножеству таблицы (например, только 2-3 столбца или только там, где Status = 1, или вы хотите получить быстрый доступ к данные, для которых требуется уродливое соединение.)
Веселье возникает, когда вы обновляете таблицу A (действительно, любую из таблиц, на которую ссылается вид), так как любые изменения в «базовой» таблице также должны быть сделаны для таблицу «view». Не очень хорошая идея в сильно используемых OLTP-системах.
FYI, я считаю, что «индексированные представления SQL» называются «материализованные представления» в Oracle. Для моих денег, Materialized View - намного лучшее имя/описание.
Это работает только в очень дорогих версиях SQL Server. –
Это сложнее, чем это. Вы можете создавать индексированные представления в любой версии SQL Server 2005 и выше, но в 2005 году есть какая-то rigamarole об издании, подсказках индексов и будет ли оптимизатор запросов рассматривать их использование или нет. В 2008 году оптимизатор запросов всегда будет рассматривать индексированные представления. –
Хотя представление не является реальным объектом, кластеризованным индексом является.
И строки, которые возвращает вид, могут быть отсортированы и сохранены.
Однако, чтобы быть индексируемым, представление должно удовлетворять ряду условий.
В основном они гарантируют, что результаты сохраняются, а обновления базовой таблицы можно легко отследить в представлении (чтобы индекс не нужно перестраивать каждый раз, когда обновляется базовая таблица).
Например, SUM(*) и COUNT_BIG(*) являются распределительными функциями:
SUM(set1) + SUM(set2) = SUM(set1 + set2)
COUNT_BIG(set1) + COUNT_BIG(set2) = COUNT_BIG(set1 + set2)
, так что можно легко пересчитать значения из SUM и COUNT_BIG при изменении таблицы, используя только просматривать строки и значение столбцов пострадавших ,
Однако это не относится к другим агрегатам, поэтому они не допускаются в индексированном виде.
Индекс всегда существует на диске. Когда вы создаете индекс, вы материализуете строки представления на диске, даже если само представление не является «реальными» строками.
MSDN White paper с объяснением
Говорят, что индексированное представление «материализует» данные вида - путем добавления кластерного индекса, в котором уровень листа является фактическими страницами данных, это именно то, что происходит. И именно по этой причине индексированный просмотр обычно намного быстрее, чем «обычный» вид. –