Создать индекс по представлению SQL с операторами UNION? Это действительно улучшит производительность? - PullRequest
15 голосов
/ 15 апреля 2009

Я пытаюсь создать индекс в следующем представлении:

SELECT     'Candidate' AS Source, CandidateID AS SourceId, LastName + ', ' + FirstName AS SourceName
FROM         dbo.Candidates
UNION
SELECT     'Resource' AS Source, ResourceID AS SourceId, LastName + ', ' + FirstName AS SourceName
FROM         dbo.Resources
UNION
SELECT     'Deal' AS Source, DealID AS SourceId, CONVERT(varchar, Number) + '-' + CONVERT(varchar, RevisionNumber) AS SourceName
FROM         dbo.Deals
UNION
SELECT     'Job Order' AS Source, JobOrderID AS SourceId, CustomerNumber AS SourceName
FROM         dbo.JobOrders

Я получаю следующую ошибку:

Msg 1939, Level 16, State 1, Line 2
Cannot create index on view '_Source' because the view is not schema bound.

Я добавил WITH SCHEMABINDING в CREATE и теперь получаю следующую ошибку:

Msg 10116, Level 16, State 1, Line 2
Cannot create index on view 'DEALMAKER.dbo._Source' because it contains one or more UNION, INTERSECT, or EXCEPT operators. Consider creating a separate indexed view for each query that is an input to the UNION, INTERSECT, or EXCEPT operators of the original view.

Мои вопросы:

Как мне создать индекс для этого представления? Будет ли работать создание отдельных индексированных представлений действительно ?

Наконец, я действительно собираюсь увидеть улучшение производительности для любых запросов, которые могут присоединиться к этому представлению?

Заранее спасибо!

Ответы [ 2 ]

20 голосов
/ 15 апреля 2009

Вы не можете создать индекс для представления, которое использует оператор объединения. На самом деле нет пути, прости!

Я полагаю, вы видели это, но посмотрите эту страницу MSDN . В нем приводятся требования к индексированным представлениям и объясняется, что они из себя представляют и как они работают.

Относительно того, увидите ли вы выигрыш в производительности, если вы МОЖЕТЕ индексировать представление, это будет полностью зависеть от размера ваших таблиц. Я бы не ожидал какого-либо влияния на создание отдельных индексированных представлений, так как предположил бы, что ваши таблицы уже проиндексированы и вы не выполняете никаких соединений или логики в представлении.

18 голосов
/ 15 апреля 2009

Почему в МИРЕ вы используете UNION?

При наличии литералов в вашем SQL-коде существует нулевой шанс, что у вас будут дубликаты. Итак, еще раз, зачем использовать UNION?

UNION заставляет возникать отличительное, и оно немного медленнее, чем DISTINCT.

Но так как у вас есть что-то похожее на это:

SELECT 'A'
UNION
SELECT 'B'
UNION
SELECT 'C'

Нет никакой возможности, что у вас когда-нибудь будут дубликаты.

Измените его на UNION ALL, и ваш запрос будет выполняться намного быстрее.

Это фундаментальный SQL - написание хорошо настроенного запроса важнее, чем создание индексов представления. Начните с основ, разберитесь с SQL, настройте ваш запрос, ЗАТЕМ беспокойтесь о расходе места и замедлении DML для повышения скорости запросов.

EDIT:

Литералы в запросе предотвращают дублирование между таблицами. Единственная оставшаяся возможность - дупс в таблице (ах). Поскольку столбцы выглядят как PK, и нет никаких объединений, которые могли бы вызвать дублирование, и поскольку все таблицы выглядят как справочные таблицы, то, что я сказал, правильно. Если это предположение неверно, то вы можете законно использовать UNION без ALL. Однако я считаю, что в 99% случаев люди действительно хотели использовать ALL, и в нашей компании принято добавлять комментарий к SQL только с помощью UNION, потому что это часто ошибка. т.е. СОЮЗ - да, мне нужен отдельный список.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...