Как отметил Джон, расширьте индекс и получите ключевые элементы, основанные на том, что можно было бы считать наименьшей гранулярностью ожидаемых результатов, исходя из критериев WHERE ... Ваш "ObjectType", являющийся строкой, мог бы быть лучше оптимизирован, если бы он был больше перечислимое целочисленное значение, чем текст тоже. Что касается зернистости. Который вернул бы наименьшее количество записей ... идентификатор состояния, состоящий из 501 и 504, объединенных (через ваше условие ИЛИ) по сравнению с типом объекта "SchemeTypeApplication". Если у 501 есть 50 000 записей, у 504 есть 30 000 записей, но у «SchemeTypeApplication» есть 475 000 записей, я бы сначала поместил свой индекс по идентификатору статуса, в противном случае, наоборот ... Пусть индекс пройдет через 80 000 записей, и в этом, как многие из 475 000 типов объектов - 501 и 504, возможно, 50 000, и все готово. Да, ваш исходный комментарий относится к возвращению около 300 тыс. Строк, но это всего лишь пример определения метода оптимизации индекса, основанного на том, как обычно будут использоваться ваши запросы. Итак, я бы индексировал что-то вроде
(statusID, ObjectType, IsDeleted, ObjectID)