Почему это сканирование индекса, а не поиск индекса
Кластерный индекс был создан на обоих 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 он действует как индексное сканирование для поиска по всей таблице данных. Вот почему сканирование индекса всегда происходит медленно.