Почему это сканирование индекса, а не поиск индекса

Кластерный индекс был создан на обоих dw_assesment_details а также dw_assesment_details_id таблицы

/* 6 minutes */
CREATE CLUSTERED INDEX [Ix_DW_ASSESSMENT_DETAILS_qid_QNO_TmpverName] 
ON [dbo].[DW_ASSESSMENT_DETAILS_QUESTION_ID]
(
    [TEMPLATENAME] ASC,
    [TEMPLATEVERSION] ASC,
    [QUESTION_NO] ASC
)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, 
      DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
GO

/* 9 minutes */
CREATE CLUSTERED INDEX [Ix_DW_ASSESSMENT_DETAILS_QNO_TmpverName] 
ON [dbo].[DW_ASSESSMENT_DETAILS]
(
    [TEMPLATENAME] ASC,
    [TEMPLATEVERSION] ASC,
    [QUESTION_NO] ASC
)
WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, 
      DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)

SELECT 
    [GETQUESTIONID], 
    dw.[TEMPLATENAME], dw.[TEMPLATEVERSION],
    dw.[QUESTION_NO]
FROM 
    [QIS_DW].[dbo].[DW_ASSESSMENT_DETAILS] dw 
INNER JOIN
    [QIS_DW].[dbo].[DW_ASSESSMENT_DETAILS_QUESTION_ID] id ON dw.TEMPLATENAME = id.TEMPLATENAME 
                                                          AND dw.TEMPLATEVERSION = id.TEMPLATEVERSION 
                                                          AND dw.QUESTION_NO = id.QUESTION_NO

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

Любое предложение от эксперта по настройке производительности?

введите описание изображения здесь

2 ответа

Что делать, чтобы вместо этого использовать поиск по индексу?

Вы можете указать LOOP JOIN запрос подсказки, если вы хотите попробовать и перехитрить оптимизатор SQL Server. Я ожидаю, что план с MERGE JOIN работать намного лучше со многими рядами.

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

Попробуйте выполнить приведенные ниже запросы, чтобы узнать, так ли это в вашей среде.

SET STATISTICS IO ON;
SET STATISTICS TIME ON;
GO

SELECT 
    [GETQUESTIONID], 
    dw.[TEMPLATENAME], dw.[TEMPLATEVERSION],
    dw.[QUESTION_NO]
FROM 
    [QIS_DW].[dbo].[DW_ASSESSMENT_DETAILS] dw 
INNER JOIN
    [QIS_DW].[dbo].[DW_ASSESSMENT_DETAILS_QUESTION_ID] id ON dw.TEMPLATENAME = id.TEMPLATENAME 
                                                          AND dw.TEMPLATEVERSION = id.TEMPLATEVERSION 
                                                          AND dw.QUESTION_NO = id.QUESTION_NO;
GO

SELECT 
    [GETQUESTIONID], 
    dw.[TEMPLATENAME], dw.[TEMPLATEVERSION],
    dw.[QUESTION_NO]
FROM 
    [QIS_DW].[dbo].[DW_ASSESSMENT_DETAILS] dw 
INNER JOIN
    [QIS_DW].[dbo].[DW_ASSESSMENT_DETAILS_QUESTION_ID] id ON dw.TEMPLATENAME = id.TEMPLATENAME 
                                                          AND dw.TEMPLATEVERSION = id.TEMPLATEVERSION 
                                                          AND dw.QUESTION_NO = id.QUESTION_NO
OPTION(LOOP JOIN);
GO

В SQL Server, поиск индекса изменений поиска в кластеризованном или некластеризованном индексе выполняется до тех пор, пока мы не добавим условие в предложении Where.

Где пункт заставит Индекс искать как план выполнения. Без предложения Where он действует как индексное сканирование для поиска по всей таблице данных. Вот почему сканирование индекса всегда происходит медленно.

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