Индекс по многобитовым полям в SQL Server

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

Рассматриваемая таблица является транзакционной таблицей, которая может содержать десятки миллионов строк, и производительность как при вставке, так и при выборе очень важна. Хотя в настоящее время мы не совсем уверены в распределении данных, комбинация всех флагов должна обеспечить относительно хорошую мощность множества, то есть сделать его "полезным" индексом для SQL Server.

Типичные сценарии выборочного запроса может быть выбор записей только на основе 3 или 4 флагов, например ГДЕ ФЛАГ3 = 1 И ФЛАГ7 = 0 И ФЛАГ9 = 1 . Было бы нецелесообразно создавать отдельные индексы для всех комбинаций флагов, используемых этими запросами на выборку, поскольку их будет много.

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

В настоящее время мы рассматриваем два основных варианта:

• Создание единого индекса который включает все битовые поля (это, вероятно, будет включать 1 или 2 других поля int , которые будут использоваться всегда). Меня беспокоит то, что, учитывая типичное использование только нескольких полей, этот подход пропустит индекс и прибегнет к сканированию таблицы. Назовем это Вариант A (Прочитав некоторые ответы, кажется, что этот подход не будет работать, так как порядок полей в индексе будет иметь значение, делая невозможным эффективное индексирование для ВСЕХ поля).
• Эффективно делать то, что, как я полагаю, SQL Server делает изнутри, и кодировать битовые поля в одно поле типа int, используя бинарные операторы (числа AND и OR вместе: 1, 2, 4, 8, так далее). Меня беспокоит то, что нам нужно будет выполнить какой-то расчет для запроса в этом закодированном поле, что снова пропустит индекс. Техническое обслуживание и сложность этого решения также вызывают беспокойство. Назовем этот Вариант B . Дополнительная информация: Аргумент для этого подхода заключается в том, что у нас может быть относительно простой и короткий индекс, который включает одно или два других поля из таблицы и это поле. Другие поля сократят количество записей, которые необходимо оценить, и, поскольку закодированное поле будет содержать все наши битовые поля, SQL Server сможет выполнить расчет, используя данные, полученные из индекса напрямую (т. Е. Сканирование индекса ) в отличие от таблицы (т.е. сканирование таблицы).

В настоящий момент мы сильно склоняемся к Варианту B . Для полноты, это будет работать на SQL Server 2008.

Мы будем очень благодарны за любые советы.

Изменить: орфография, ясность, пример запроса, дополнительная информация по Вариант B .