Как уменьшить стоимость сканирования кластерного индекса с помощью SQL-запроса

Как уменьшить стоимость сканирования кластерного индекса ниже указанного запроса

DECLARE @PARAMVAL varchar(3)

set @PARAMVAL = 'CTD'
select * from MASTER_RECORD_TYPE where [email protected]

если я запускаю указанный выше запрос, он показывал индексное сканирование 99%

Пожалуйста, ознакомьтесь со следующими особенностями моего стола:

здесь ниже я вставил свой индекс для таблицы:

CREATE TABLE [dbo].[MASTER_RECORD_TYPE] ADD  CONSTRAINT [PK_MASTER_REPORD_TYPE] PRIMARY KEY CLUSTERED 
(
    [Record_Type_Id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 80) ON [PRIMARY]
GO

любезно сообщите, как я могу снизить стоимость сканирования индекса?

Ответ 1

Прежде всего - если вы ищете RECORD_TYPE_CODE, вы должны иметь индекс в этом столбце.

Кроме того, в основном две вещи:

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

Если у вас есть такой некластеризованный индекс покрытия, то оптимизатор запросов, скорее всего, будет использовать этот индекс покрытия (вместо фактического кластерного индекса, который является полными данными таблицы), чтобы получить результаты

Ответ 2

Вам нужно попытаться использовать закрытый индекс. Но проблема, с которой вы столкнулись, заключается в том, что вы используете SELECT *. Вам действительно нужна полная запись?

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

Ответ 3

В вашем запросе вы использовали столбец RECORD_TYPE_CODE, который не является частью clustered index, а также не включен в любой non-clustered index. Поэтому SQL Optimizer решит сканировать кластерный индекс, чтобы выполнить сравнение предиката where where.

Почему происходит сканирование моего кластерного индекса?