Как MongoDB решает, какой индекс одного поля использовать, если для одного и того же поля существуют дубликаты?

Question

Возможно создание двух индексов одного поля для одного и того же поля, когда один возрастает, а другой убывает.

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

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

Запросы этого коллекция для документов с указанным ненулевым полем c всегда будет использовать нисходящий индекс - даже если в этом случае это будет неуникальный индекс, содержащий документы с нулевым полем, а восходящий индекс - нет.

Answer 1

Когда планировщик запросов в первый раз видит указанную форму запроса c, он выполняет этап планирования, на котором он рассматривает применимые индексы, выполняет запрос в течение короткого времени с использованием каждого индекса, а затем выбирает план, который вернул наибольшее количество документов. с наименьшей работой. Он кэширует выбранный план, поэтому планирование не нужно выполнять каждый раз, когда выполняется запрос. См. Планы запросов для получения дополнительной информации.

Вы можете увидеть планы, которые были рассмотрены для определенного c запроса, и как каждый выполнялся с использованием , объясните с помощью "allPlansExection" "option.

Исполнитель запроса может использовать индекс в прямом или обратном направлении. Используемое указывается в плане объяснения.

Это означает, что если вы запрашиваете {key: xxx} или сортируете по {key:1}, можно использовать индекс {key:-1}.

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

В вашем случае один из индексов является частичным, поэтому, когда планировщик запросов проверяет, он должен найти, что частичный индекс работает намного лучше, чем другой индекс.

Однако обычно существует ограничение на создание индекса для одних и тех же полей с разными параметрами, и вы, похоже, обошли это путем изменения порядка сортировки. Я не знаю, будет ли это сбивать с толку планировщика запросов, поэтому вам, вероятно, следует протестировать объяснение с различными запросами, которые вы собираетесь использовать, чтобы убедиться, что он выполняет то, что вы ожидаете.

Если планировщик запросов этого не делает последовательно выбирая правильный индекс, вы можете подсказать, какой из них вы хотите использовать, и обойтись без проверки планировщика.