Оптимизация КЛАСТЕРНОГО ИНДЕКСА для использования с JOIN

Question

Таблица optin_channel_1 (для каждого "канала" есть отдельная таблица)

CREATE TABLE [dbo].[optin_channel_1](
    [key_id] [bigint] NOT NULL,
    [valid_to] [datetime] NOT NULL,
    [valid_from] [datetime] NOT NULL,
    [key_type_id] [int] NOT NULL,
    [optin_flag] [tinyint] NOT NULL,
    [source_proc_id] [int] NOT NULL,
    [date_inserted] [datetime] NOT NULL
) ON [PRIMARY]

CREATE CLUSTERED INDEX [ix_id] ON [dbo].[optin_channel_1] 
(
    [key_type_id] ASC,
    [key_id] ASC,
    [valid_to] ASC,
    [valid_from] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

Таблица profile_conns

CREATE TABLE [dbo].[profile_conns](
    [profile_key_id] [bigint] NOT NULL,
    [valid_to] [datetime] NOT NULL,
    [valid_from] [datetime] NOT NULL,
    [conn_key_id] [bigint] NOT NULL,
    [conn_key_type_id] [int] NOT NULL,
    [conn_type_id] [int] NOT NULL,
    [source_proc_id] [int] NOT NULL,
    [date_inserted] [datetime] NOT NULL
) ON [PRIMARY]

CREATE CLUSTERED INDEX [ix_id] ON [dbo].[profile_conns] 
(
    [profile_key_id] ASC,
    [conn_key_type_id] ASC,
    [conn_key_id] ASC,
    [valid_to] ASC,
    [valid_from] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

Таблица lu_channel_conns

CREATE TABLE [dbo].[lu_channel_conns](
    [channel_id] [int] NOT NULL,
    [conn_type_id] [int] NOT NULL,
 CONSTRAINT [PK_lu_channel_conns] PRIMARY KEY CLUSTERED 
(
    [channel_id] ASC,
    [conn_type_id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

Таблица lu_conn_type

CREATE TABLE [dbo].[lu_conn_type](
    [conn_type_id] [int] NOT NULL,
    [default_key_type_id] [int] NOT NULL,
    [master_key_type_id] [int] NOT NULL,
    [date_inserted] [datetime] NOT NULL,
 CONSTRAINT [PK_lu_conns] PRIMARY KEY CLUSTERED 
(
    [conn_type_id] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

Посмотреть v_source_proc_id_by_group_id

SELECT DISTINCT x.source_proc_id, x.source_proc_group_id
FROM lu_source_proc x INNER JOIN lu_source_proc_group y ON x.source_proc_group_id = y.group_id

Будет выполнено динамическое SQL-выражение:

SET @sql_str='SELECT @ret=MAX(o.optin_flag)
    FROM optin_channel_'+CAST(@channel_id AS NVARCHAR(100))+' o
    INNER HASH JOIN dbo.v_source_proc_id_by_group_id y ON o.source_proc_id=y.source_proc_id AND y.source_proc_group_id=@source_proc_group_id
    INNER HASH JOIN profile_conns z ON z.profile_key_id=cast(@profile_key_id AS NVARCHAR(100)) AND z.conn_key_type_id=o.key_type_id AND z.conn_key_id=o.[key_id] AND z.valid_to=''01.01.3000''
    INNER HASH JOIN lu_channel_conns x ON x.channel_id=@channel_id AND z.conn_type_id=x.conn_type_id
    INNER HASH JOIN lu_conn_type ct ON ct.conn_type_id=x.conn_type_id AND ct.default_key_type_id=o.key_type_id'
SET @param='@channel_id INT, @profile_key_id INT, @source_proc_group_id INT, @ret NVARCHAR(400) OUTPUT'
EXEC sp_executesql @sql_str,@param,@channel_id,@profile_key_id,@source_proc_group_id,@ret OUTPUT

Т.е. это дает:

SELECT @ret=MAX(o.optin_flag) AS optin_flag
FROM optin_channel_1 o
INNER HASH JOIN dbo.v_source_proc_id_by_group_id y 
    ON o.source_proc_id=y.source_proc_id 
    AND y.source_proc_group_id=5
INNER HASH JOIN profile_conns z 
    ON z.profile_key_id=1 
    AND z.conn_key_type_id=o.key_type_id 
    AND z.conn_key_id=o.[key_id] 
    AND z.valid_to='01.01.3000'
INNER HASH JOIN lu_channel_conns x 
    ON x.channel_id=1 
    AND z.conn_type_id=x.conn_type_id
INNER HASH JOIN lu_conn_type ct 
    ON ct.conn_type_id=x.conn_type_id 
    AND ct.default_key_type_id=o.key_type_id

Эти таблицы используются для базы данных optin. optin_flag может быть 0 или 1. С последним утверждением я хочу получить 1 как optin_flag от optin_channel_1 для данного channel_id=1 для пользователя с profile_key_id=1, когда optin был вставлен в базу данных процессом, принадлежащим source_proc_group_id=5, Я надеюсь, что этого достаточно, чтобы понять, что происходит.

Это лучший способ использовать CLUSTERED INDEX"ы? Или лучше удалить profile_key_id из индекса на profile_conns и положи z.profile_key_id=1 в WHERE статья?

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

Answer 1

Не зная размера таблиц и вида хранимых в них данных, их трудно измерить.

Предполагая, что optin_channel_1 имеет много данных, а profile_cons имеет много данных, я бы попробовал следующее:

• Кластерный индекс для optin_channel_1(key_id) или key_type_id в зависимости от того, какое поле имеет наиболее различимые значения. (так как у вас нет индекса покрытия)
• Кластерный индекс для profile_conns (cons_key_id) или cons_key_type_id в зависимости от того, что вы выбрали в optin_channel_1
• так далее...

По сути, если ваша таблица profile_conns содержит мало данных, я бы поместил кластерный индекс в самое фрагментированное поле "фильтра" (я подозреваю, profile_key_id). Если в таблице много данных, я бы стремился к объединению хеша / слияния и сопоставлял кластеризованный индекс с кластеризованным индексом таблицы optin_channel_1.

Я бы также переписал запрос так:

SELECT @ret = MAX(o.optin_flag) AS optin_flag
  FROM optin_channel_1 o
  JOIN dbo.v_source_proc_id_by_group_id y 
    ON o.source_proc_id = y.source_proc_id  
  JOIN profile_conns z 
    ON z.conn_key_type_id = o.key_type_id 
   AND z.conn_key_id = o.[key_id] 
  JOIN lu_channel_conns x 
    ON z.conn_type_id = x.conn_type_id
  JOIN lu_conn_type ct 
    ON ct.conn_type_id = x.conn_type_id 
   AND ct.default_key_type_id=o.key_type_id 
 WHERE y.source_proc_group_id = 5
   AND z.profile_key_id = 1 
   AND x.channel_id = 1 
   AND z.valid_to = '01.01.3000'

Запрос изменился таким образом, потому что:

• Помещение условий фильтра в предложение where показывает, какие релевантные поля предназначены для объединения хэшей / слияний.
• Вводить подсказки о присоединении редко бывает хорошей идеей. Очень сложно превзойти регулятор запросов, чтобы определить лучший план запроса. Плохой план обычно означает, что у вас есть проблема с вашими индексами / статистикой.

Итак, как резюме:

• маленькая таблица, соединенная с большой таблицей ==> перейдите к вложенным циклам и сфокусируйте свой кластерный индекс на поле "фильтр" в маленькой таблице и поле соединения в большой таблице.
• большая таблица соединяется с большой таблицей => перейти к объединению хэшей / слиянием и поместить кластерный индекс в соответствующее поле с обеих сторон
• Многопольные индексы обычно являются хорошей идеей, когда они "покрывают", это означает, что все поля, которые вы запрашиваете, включены в индекс. (или включены в предложение include())