aleksrovuaggster,
Вы же должны понимать, что при запросе isAсtive = 1 SQL не будет использовать никакой индекс, если у вас 100 лямов записей и грубо говоря 50 это isActive = 0 и 50 isActive = 1, SQL в любом случае будет делать скан, более того вы выбираете * (пропишите нормально столбцы, не звездочкой), т.е. если вым нужны все столбы покрывающий индекс вы тоже не сделаете.
Если бы у вас таблица была широкая, а нужно было вам всего несколько столбцов можно было создать индекс для них, один фиг это был бы скан, но гораздо меньшего кол-ва страниц, у нас к примеру таких индексов много.
У вас единственное место где можно немного оптимизировать это order by, но это оптимизация будет настолько ничтожной по сравнению со сканом всей таблицы, что разницы вы не заметите.

Есть выход! Фильтрованный индекс, точнее - два.

uaggsteraleksrovuaggster,
Вы же должны понимать, что при запросе isAсtive = 1 SQL не будет использовать никакой индекс, если у вас 100 лямов записей и грубо говоря 50 это isActive = 0 и 50 isActive = 1, SQL в любом случае будет делать скан, более того вы выбираете * (пропишите нормально столбцы, не звездочкой), т.е. если вым нужны все столбы покрывающий индекс вы тоже не сделаете.
Если бы у вас таблица была широкая, а нужно было вам всего несколько столбцов можно было создать индекс для них, один фиг это был бы скан, но гораздо меньшего кол-ва страниц, у нас к примеру таких индексов много.
У вас единственное место где можно немного оптимизировать это order by, но это оптимизация будет настолько ничтожной по сравнению со сканом всей таблицы, что разницы вы не заметите.
Таблица, на самом деле - широкая, сотни три полей.
И битовых критериев - больше трёх (с десяток - точно).
Теоретически, комбинация нескольких критериев дает довольно большую селективность, но всё равно в такой выборке, в типичном случае, вылазит в пределах миллиона записей.
Выборки используются потом для построения каких-то агрегатов, т.е. это такое окно, что-ли.
Проблема в том, что комбинаций этих критериев, в общем, чертова куча используется.
Но, опять же, теоретически, я готов проанализировать, какие комбинации использовать, и построить что-то типа (DTA, isAсtive, isInvalid, isOverlapped, ...), ну, хотя бы некоторые запросы. Но неужели это единственный вариант?
(и будет ли толк вообще).

1. Можно вычисляемое поле забабахать и фсе биты туды сложить.
2. Теоретически сервер умеет делать index intersection. Т.е. два фильтрованных индекса на каждое битовое поле имеют право на существование.

aleksrovaleks222,

По сути нужно будет создвть с десяток фильтрованных индексов с include как я понимаю всей таблицы, как было сказано это все ровно не взлетит, да и по месту, по сути копия таблицы будет, хотя читать 1\10 таблицы конечно быстрее будет.

Include, в данном случае, НЕ НУЖНО.
После Index Intersection будет Lookup кластерного.