Как SQL Server знает, как заблокировать объекты просмотра?

В SQL Server 2008 у меня есть представление V поверх таблиц A и B, которые выглядят примерно как

create view V as
    select * from A
    union all
    select * from B

Чтение из V приводит к тому, что запрос принимает блокированные общие блокировки в базовых таблицах, но также принимает намеренную общую блокировку для самого объекта представления.. p >

Понятно, почему нам нужны блокировки IS в таблицах, и мы видим, что блокировка IS в представлении предотвращает параллельную модификацию таблиц, лежащих в основе представления. Это прекрасно.

В плане запроса нет упоминания о представлении. Он полностью скомпилирован, и результирующий план в этом случае представляет собой простую конкатенацию строк из двух базовых таблиц. Действительно, единственное упоминание о представлении в XML-плане запроса содержится в тексте инструкции.

Если вы добавите второе представление U по таблицам, чтение из V не приведет к блокировке на U. Это исключает, что движок просто берет блокировку IS во всех видах над A и B.

Как механизм базы данных знает, чтобы сделать блокировку в представлении?

Повторяется ли текст инструкции?
Есть ли какой-либо другой канал информации между планировщиком запросов и базовым исполнением, чтобы передать эту информацию?

Дополнительную информацию см. в соответствующем вопросе на dba.stackexchange.

Ответ 1

Копирование из моего ответа на dba.stackexchange:

Из Конор Каннингем, конечный источник чего-то связанного с двигателем или оптимизатором:

Мы отслеживаем вещи во время компиляции для проверки во время выполнения. Мы не разбираем вещи при исполнении для этой цели.

Примечание: внутренности того, что мы делаем из одного выпуска в другой, не являются гарантировано. Это ниже официально поддерживаемой площади.

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

Ответ 2

Если вы посмотрите на sys.dm_exec_query_optimizer_info, который возвращает данные оптимизатора запросов SQL Server, одна из возвращаемых деталей следующая: поле:

ссылка на просмотр - количество обращений к запросу в запросе.

Казалось бы, количество раз, на которое ссылается представление, отслеживается где-то, возможно, как часть плана выполнения... мое предположение заключается в том, что даже если представление расширено, в плане выполнения по-прежнему содержатся сведения о том, какие представления были используемый в запросе, и выдает соответствующие блокировки IS против этих ссылочных представлений.

Ответ 3

По умолчанию представления расширяются, как макрос, в запросы, которые ссылаются на них.

Это может быть отключено или изменяться, если они материализованы и т.д., но макро-подобное встроенное расширение является нормой. Это означает, что блокировка и т.д. Ведет себя так, как если бы вы сделали следующее...

SELECT
  *
FROM
  blah
INNER JOIN
(
  yourViewCode
)
  AS aView
    ON aView.id = blh.id