Множественный составной индекс против одного некластеризованного индекса хранилища столбцов

У нас есть система OLTP, и у нас есть сетка, содержащая около 20 столбцов, поступающих из нескольких таблиц. Сетка загружается на основе параметров поиска, включающих около 6 столбцов. Данные огромны: 100 миллионов строк поступают из фоновых таблиц.

Чтобы повысить производительность загрузки сетки, мы создали индексированное представление с одним уникальным кластеризованным индексом. В настоящее время мы хотим посмотреть, как мы можем улучшить производительность параметров поиска: a,b,c,d,e,f

Поиск может быть основан на любой комбинации: (а), (а, в), (г, д), (а, б, в) ... (а, б, в, г, д, е)

Мы думаем о том, чтобы выбрать один из следующих вариантов:

  • Несколько составных индексов в индексированном представлении с определенными шаблонами доступа, такими как (a, b), (b, d), (a, b, c) и т. д.
  • Единый некластеризованный индекс columnstore в индексированном представлении, который будет полезен для удовлетворения всех различных шаблонов доступа, таких как (a, b), (b, d), (a, b, c) и т. д. с включенным столбцом из 20 столбцов.

Не подскажете, какой подход лучше?

ОБНОВЛЕНИЕ. Только что прочитал, что некластеризованный индекс хранилища столбцов не поддерживает включение столбцов. Попробую дальше и обновлю ответ либо комментариями, если вопрос закрыт, либо ответив на него.


sql-server azure-sql-managed-instance columnstore non-clustered-index indexed-view
person Venkataraman R    schedule 27.01.2021    source источник
comment
У вас есть ваши фактические данные, возможность реализовать альтернативы и сопоставить их с реальными шаблонами запросов, которые важны для вас. Как вы думаете, почему незнакомцы в Интернете, не имеющие ни одной из этих вещей, не смогут дать вам окончательный ответ?   -  person Damien_The_Unbeliever    schedule 27.01.2021
comment
@Damien_The_Unbeliever, я с тобой согласен. Я не был уверен, будет ли некластеризованный индекс хранилища столбцов поддерживать разные шаблоны поиска. Поскольку это огромный объем данных, хотелось получить некоторые варианты, прежде чем пробовать. Ты прав. Попробую с данными и обновлю этот вопрос с ответом.   -  person Venkataraman R    schedule 27.01.2021
comment
Ничего из вышеперечисленного, потому что нужно учитывать слишком много вариантов, вам понадобится много индексов. В лучшем случае я бы сделал индексы с одним или двумя столбцами (в зависимости от того, насколько избирательным является первый столбец) для нескольких популярных столбцов, все, что шире, - это пустая трата времени, потому что вам все равно понадобится поиск по ключу. Вы также должны учитывать что-то вроде OPTION(RECOMPILE) в своем запросе   -  person Charlieface    schedule 27.01.2021
comment
@Чарлифейс, спасибо. Теперь также происходит поиск ключей, поскольку мы извлекаем ~ 20 столбцов из индексированного представления.   -  person Venkataraman R    schedule 27.01.2021
comment
См. также #BackToBasics: пример обновленной кухонной раковины   -  person Charlieface    schedule 27.01.2021
comment
@Charlieface, не могли бы вы добавить это в качестве ответа, я приму то же самое. Мы уже делаем только динамический sql. Мы попробуем добавить конкретные индексы для шаблона и посмотрим, сработает ли это.   -  person Venkataraman R    schedule 27.01.2021

Ответы (1)


arrow_upward
1
arrow_downward

Поскольку существует так много комбинаций, которые нужно учитывать, вам потребуется много индексов.

Итак, самое большее, я бы сделал индексы с одним или двумя столбцами (в зависимости от того, насколько избирательным является первый столбец) для нескольких популярных столбцов. Все, что шире, — пустая трата времени, потому что индекс в любом случае будет избирательным.

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

Вы также должны учитывать что-то вроде OPTION (RECOMPILE) в своем запросе. См. #BackToBasics: пример обновленной кухонной раковины от Аарон Бертран.

person Charlieface    schedule 27.01.2021