Как исправить низкую производительность в представлении T-SQL

У меня есть приложение ASP.NET MVC, использующее представление T-SQL, которое я создал как часть своей модели данных. Я могу использовать данные обзора, но у меня очень низкая производительность.Как исправить низкую производительность в представлении T-SQL

Если я делаю SELECT * на вид в SQL Server 2008, для возврата всех 187,101 строк требуется более 20 минут.

Если у меня есть SELECT TOP 1000000 на вид, я получаю те же самые 187,101 строк, возвращаемых за 2 секунды.

Итак, я включил оператор TOP в свой дизайн, чтобы попытаться получить лучшую производительность в приложении ASP.NET MVC, но для загрузки результатов в WebGrid по-прежнему требуется ~ 6 секунд.

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

Вот SELECT заявление, которое я использовал, чтобы создать свою точку зрения:

SELECT TRD.Description AS Pbm, 
     MV.ExtractHistoryMemberValueId, 
     MV.FieldDescription, 
     MV.FieldValue, 
     HM.ExtractHistoryMemberId, 
     HM.CaseNum, 
     HM.CertNum, 
     HM.ClmtNum, 
     HM.PlanNum, 
     EH.ExtractHistoryId, 
     EH.ExtractDate 
FROM OutgoingAccumulators.ExtractHistoryMemberValues AS MV 
    INNER JOIN OutgoingAccumulators.ExtractHistoryMembers AS HM 
     ON (MV.ExtractHistoryMember = HM.ExtractHistoryMemberId) 
    INNER JOIN OutgoingAccumulators.ExtractHistories AS EH 
     ON (HM.ExtractHistory = EH.ExtractHistoryId) 
    INNER JOIN OutgoingAccumulators.Extracts AS EX 
     ON (EH.Extract = EX.ExtractId) 
    INNER JOIN Accumulators.Interfaces AS INF 
     ON (EX.Interface = INF.InterfaceId) 
    INNER JOIN Accumulators.TradingPartners AS TRD 
     ON (INF.TradingPartner = TRD.TradingPartnerId)

Вот изображение конструкции вида:

view

источник

2013-05-24 Splendor

Существуют индексы на всех полях соединяемых на? Вам действительно нужны все столбцы? –

@MarkCanlas К сожалению, мне действительно нужно захватить все эти столбцы. Я не уверен на 100% относительно части индекса вашего вопроса; есть отношения первичного/внешнего ключа на каждом соединенном поле. – Splendor

FKs подразумевают индексы, поэтому ответ «да». Я бы постарался начать ваши запросы только с базовой таблицей, а затем придерживаться одного соединения за раз, чтобы увидеть, где ваш запрос начинает страдать. Существует ли какая-либо блокировка, одновременное чтение и запись в одни и те же таблицы? Вы объединяете несколько запросов «один ко многим»? –

Я нашел решение. Я добавил не-кластерный индекс к таблице ExtractHistoryMemberValues так:

USE [ProcessingDB] 
GO 
CREATE NONCLUSTERED INDEX [IX_ExtractHistoryMember] 
ON [OutgoingAccumulators].[ExtractHistoryMemberValues] ([ExtractHistoryMember]) 
INCLUDE ([ExtractHistoryMemberValueId],[FieldDescription],[FieldValue]) 
GO

мнение теперь возвращает все строки в течение 2 секунд.

Вот новый план выполнения: http://i.imgur.com/CiWkFT7.png

источник

2013-05-29 14:20:49 Splendor

Как исправить низкую производительность в представлении T-SQL

ответ

Смежные вопросы