Индекс советуют SQL Server 500M записей

Question

У меня есть таблица со следующей структурой:

primary+foreignkey1
primary+foreignkey2
primary+foreignkey3
primary+foreignkey4
primary+foreignkey5
primary+foreignkey6
string
int
varbinary

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

В настоящее время производительность очень и очень плохая.Простые запросы занимают много времени.Данные меняются каждые 2 года, поэтому они очень статичны.

В настоящее время у нас есть только кластеризованный индекс для всех значений pk:

CREATE TABLE table(
    [id1] [int] NOT NULL,
    [id2] [int] NOT NULL,
    [id2] [int] NOT NULL,
    [id4] [int] NOT NULL,
    [id5] [int] NOT NULL,
    [id6] [int] NOT NULL,
    [location] [varchar](50) NOT NULL,
    [year] smallint NOT NULL,
    [text] [decimal](10, 4) NULL,
    [hash] [varbinary](50) NOT NULL,
 CONSTRAINT [pk_1] PRIMARY KEY CLUSTERED 
(
    id1 ASC,
    id2 ASC,
    id3 ASC,
    id4 ASC,
    id5 ASC,
    id6 ASC,
    location ASC,
    year asc

)

Может кто-нибудь посоветовать мне индекс наилучшей практики для оптимизации производительности при запросе таблицы?

Спасибо!

Answer 1

(Отказ от ответственности: этот пост основан на личном мнении)

Во-первых , ваш кластерный первичный ключ выглядит немного бессмысленным:

CONSTRAINT [pk_1] PRIMARY KEY CLUSTERED 
(
    id1 ASC,
    id2 ASC,
    id3 ASC,
    id4 ASC,
    id5 ASC,
    id6 ASC,
    location ASC,
    year asc
)

• Это вряд ли гарантирует какую-либо уникальность, потому что там размещены почти все колонки,
• замедляет вставки
• делает все остальные некластеризованные индексы бессмысленными, поскольку они будут содержать все перечисленные столбцы кластеризованного индекса во всех некластеризованных индексах.
• Это может быть более или менее полезным только при поиске значений в столбце id1

Во-вторых , не видя ваших запросов, трудно сделать какие-либо выводы, за исключением того, что, очевидно, у вас есть datamart со звездообразной схемой. Microsoft представила индексы хранилища столбцов для такой аналитической нагрузки.

Чтобы подчеркнуть сказанное выше, индексы Clustered Columnstore создаются по умолчанию для таблиц Azure SQL Datawarehouse, поэтому в случае агрегации на больших наборах данных он действительно ярко светит

Следовательно, из-за звездообразной схемы, количества строк и очевидной аналитической нагрузки, просто общий совет :

• Попробуйте попробовать кластеризованный индекс хранилища столбцов в таблице фактов. Это будет один индекс, но он охватывает все столбцы
• Рассмотрите возможность сохранения ссылочной целостности на стороне ETL.