Производительность неиспользуемых полей в представлении SQL

Я использую MS SQL Server.

Когда я определяю схему базы данных, я определяю (нематериализованное) представление, которое включает в себя множество полей, например, как показано ниже (где «Тема» - это имя таблицы, а представление - это самосоединение в таблице «Тема») :

CREATE VIEW View_Topic_Ancestor AS
SELECT
    Subordinate.Id AS Subordinate_Id,
    Subordinate.Folder_Id AS Subordinate_Folder_Id,
    Subordinate.topicTitle AS Subordinate_topicTitle,
    Subordinate.topicXhtml AS Subordinate_topicXhtml,
    Subordinate.crossLinked AS Subordinate_crossLinked,
    Superior.Id AS Superior_Id,
    Superior.topicTitle AS Superior_topicTitle,
    Superior.topicXhtml AS Superior_topicXhtml,
    Superior.crossLinked AS Superior_crossLinked
FROM Topic AS Subordinate LEFT OUTER JOIN Topic AS Superior
ON Superior.Folder_Id = Subordinate.Folder_Id
AND 
Superior.LeftValue = (SELECT MAX(Ancestor.LeftValue)
    FROM Topic AS Ancestor
    WHERE Subordinate.LeftValue > Ancestor.LeftValue
    AND Subordinate.LeftValue < Ancestor.RightValue
    AND Subordinate.Folder_Id = Ancestor.Folder_Id)

Позже (во время выполнения) я использую это представление в операторе выбора, например:

SELECT
    T.Id AS Shared_Id,
    V.Superior_Id,
    V.Superior_topicTitle,
    V.Subordinate_Id,
    V.Subordinate_Folder_Id,
    V.Subordinate_topicXhtml
FROM Topic AS T, View_Topic_Ancestor AS V
WHERE Folder_Id='e2eb2b68-738d-49ad-9787-a1e655b7973f'
AND T.crossLinked = V.Subordinate_Id

Этот оператор SELECT не ссылается (не выбирает) многие поля, которые находятся в представлении: например, он выбирает поле Subordinate_topicXhtml, но не выбирает поле Superior_topicXhtml.

Мои вопросы:

1) Сильно ли влияют на производительность поля, определенные в представлении, но не указанные в выборе времени выполнения из представления? Предположим, если хотите, что поле Superior_topicXhtml содержит много данных (это очень длинная строка).

2) Как я могу сам проверить ответ на этот вопрос? Является ли тестирование (измерение затраченного времени с помощью секундомера) единственным способом или возможно получить ответ, основанный на теории? Я использую «Microsoft Server SQL Management Studio» для Microsoft SQL Server 2008 с SQL Express. Я вижу, как получить (но не научился интерпретировать) «предполагаемый план выполнения» для этого запроса, но он показывает только, какие индексы и циклы происходят, а не извлекаются ли данные из полей, на которые нет ссылок.

ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
Понимание Python и переход к SQL
Понимание Python и переход к SQL
Перед нами лабораторная работа по BloodOath:
3
0
1 861
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

Оптимизатор запросов создает план запроса, объединяя sql, который определяет представление, с sql, который вы создаете для «выбора» из представления, в один запрос sql. Если в этом комбинированном оптимизированном sql какой-либо конкретный атрибут (столбец) не нужен, он не будет использоваться .. в частности, если окончательный выбор не требует этого, он не будет отправлен по сети. Кроме того, если это не требуется ни для какого предложения Where, или для Order By или чего-либо еще в оптимизированном sql, и все атрибуты, которые необходимы, оказываются в индексе, тогда этот запрос может читать только индекс, а не касаться таблица вообще ... даже подумал, что просмотр ссылается на столбец, отсутствующий в индексе ... Вы можете убедиться в этом, посмотрев на план выполнения запроса для этого запроса.

Думаю, вы правы: я не предполагал, что значения полей, на которые нет ссылок, будут передаваться по сети. Чего я не знал, так это того, будут ли они считаны в память на сервере SQL.

ChrisW 30.12.2008 00:10

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

Charles Bretana 30.12.2008 00:24

Когда вы говорите «вся строка должна быть прочитана с диска», включает ли это поля типа «nvarchar (max)»? Я догадывался, что такие значения полей не хранятся встроенными (на той же странице, что и) строки / записи фиксированной длины и не обязательно и неявно извлекаются при извлечении остальной части строки?

ChrisW 30.12.2008 00:42

Да, если обработчик запросов должен прочитать что-либо из таблицы, он читает всю строку. Это связано с тем, что наименьший фрагмент данных, который он может прочитать, представляет собой одну 8-килобайтную «страницу» дискового пространства, и строки не могут занимать разные страницы.

Charles Bretana 30.12.2008 01:00

Крис, извините, я пропустил ваш комментарий об отсутствии встроенных полей varChar (max) ... Если это так, то это исключение ... Я этого не знал ...

Charles Bretana 30.12.2008 17:41

Когда у вас есть план выполнения запроса, отображаемый в Management Studio, вы можете использовать мышь, чтобы навести курсор на узлы в плане выполнения.

При наведении указателя мыши отображается большая всплывающая подсказка: которая включает «Список вывода» полей, извлеченных этим узлом, и поля «Приблизительное количество строк», которые показывают, сколько экземпляров этих полей прочитано.

Другие вопросы по теме