Структура индекса для максимальной скорости в любой комбинации столбцов индекса

Question

У меня есть база данных с пятью возможными столбцами индекса, все из которых полезны по-разному. Назовем их System, Source, Heat, Time и Row. Использование System и Row вместе создаст уникальный ключ, и если отсортировать по System-Row, база данных также будет сортироваться для любой комбинации из пяти индексных переменных (в том порядке, в котором я перечислял их выше).

Моя проблема заключается в том, что я использую все комбинации этих столбцов: иногда я хочу ПРИСОЕДИНИТЬ каждую Системную строку к следующей Системе (строка + 1), иногда я хочу GROUP или WHERE посредством System-Source-Heat, иногда я хочу посмотреть все записи System-Source WHERE Время находится в определенном окне и т. д.

В принципе, я хочу структуру индекса, которая функционирует аналогично каждой возможной перестановке этих пяти индексов (в правильном порядке, конечно), фактически не делая каждую перестановку (хотя я готов сделать это, если это необходимо). Я занимаюсь статистикой/аналитикой, а не традиционной работой с базами данных, поэтому размер индекса и скорость его создания/обновления не являются проблемой; Меня волнует только ускорение моих импровизированных запросов, поскольку я склонен их придумывать, запускать их, ждать 5-10 минут, а затем никогда не использовать их снова. Таким образом, моя главная задача - сократить «подождать 5-10 минут» на что-то большее, например «подождать 1-2 минуты».

Мои отсортированные данные будут выглядеть примерно так:

Sys So H Ti R 
1 1 0 .1 1 
1 1 1 .2 2 
1 1 1 .3 3 
1 1 2 .3 4 
1 2 0 .5 5 
1 2 0 .6 6 
1 2 1 .8 7 
1 2 2 .8 8 

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

Answer 1

Прошу прощения за то, что уделил мне время, чтобы вернуться к этому, мне нужно было поработать над чем-то еще в течение нескольких недель. В любом случае, попробовав кучу вещей (в том числе все предлагаемое здесь, даже метод грубой силы «сделать индекс для каждого метода перестановок»), я не нашел никакого метода индексирования, который значительно улучшает производительность.

Однако я нашел альтернативное, неиндексирующее решение: выбирая только строки и столбцы, которые меня интересуют в промежуточные таблицы, а затем работаю с ними вместо полной таблицы (поэтому я использую около 5 мил строк из 6 колос вместо 30 мил строк 35 колос). Первоначальное создание select и table немного медленное, но шаги после этого намного быстрее, я фактически экономит время, даже если я его запускаю только один раз (и учитывая, как часто я меняю вещи, это обычно много раз).

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

Answer 2

Если вы ТОЛЬКО, связанный с скоростью SELECT и не заботясь о INSERT, тогда вы можете материализовать ВСЕ комбинации в виде INDEXED. Вам нужно всего лишь 24 раза хранить исходную таблицу, составляя одну таблицу и 23 INDEXED VIEWs по 5 столбцов каждый.

например.

create table data (
    id int identity primary key clustered, 
    sys int, 
    so int, 
    h float, 
    ti datetime, 
    r int); 
GO 
create view dbo.data_v1 with schemabinding as 
    select sys, so, h, ti, r 
    from dbo.data; 
GO 
create unique clustered index cix_data_v1 on data_v1(sys, h, ti, r, so) 
GO 
create view dbo.data_v2 with schemabinding as 
    select sys, so, h, ti, r 
    from dbo.data; 
GO 
create unique clustered index cix_data_v2 on data_v2(sys, ti, r, so, h) 
GO 

-- and so on and so forth, keeping "sys" anchored at the front 

ли к сведению, однако
Q. Why isn't my indexed view being picked up by the query optimizer for use in the query plan? (поиск в связанной статье)

---

Если пространство является проблемой, то следующая лучшая вещь, чтобы создать индивидуальные индексы по каждому из 4-х колонок, ведущий с системой, т.е. (sys, ti), (sys, r) и т. д. Они могут использоваться вместе, если это поможет запросу, иначе оно вернется к полному сканированию таблицы.