Я использую Mongo 4.2 (застрял на этом) и имею коллекцию product_data с документами со следующей схемой:
_id:"2lgy_itmep53vy"
uIdHash:"2lgys2yxouhug5xj3ms45mluxw5hsweu"
userTS:1494055844000
Случай 1. При этом у меня есть следующие индексы для коллекции:
- _id:Обычный - Уникальный
- uIdHash: Хэшированный
я пытался выполнить
db.product_data.find( {"uIdHash":"2lgys2yxouhug5xj3ms45mluxw5hsweu"}).sort({"userTS":-1}).explain()
и это этапы в результате:
Конечно, я мог понять, что имело бы смысл иметь дополнительный составной индекс, чтобы избежать этапа сортировки в памяти mongo.
Случай 2: теперь я попытался добавить еще один индекс к уже существующим 3. {uIdHash:1, userTS:-1}: обычный и составной
Как я и ожидал, результат выполнения здесь удалось оптимизировать на этапе сортировки:
Пока все хорошо, теперь, когда я хочу создать разбиение на страницы поверх этого запроса. Мне нужно ограничить запрашиваемые данные. Следовательно, запрос далее переводится в
db.product_data.find( {"uIdHash":"2lgys2yxouhug5xj3ms45mluxw5hsweu"}).sort({"userTS":-1}).limit(10).explain()
Результат для каждого случая теперь выглядит следующим образом:
Результат ограничения случая 1: 
Сортировка в памяти работает меньше (36 вместо 50) и возвращает ожидаемое количество документов. Достаточно справедливо, хорошая базовая оптимизация на этапе.
Результат ограничения случая 2: 
Удивительно, но с используемым индексом и запрошенными данными к обработке добавлен дополнительный этап Limit!
Сомнения теперь у меня следующие:
- Зачем нам дополнительный этап для LIMIT, когда у нас уже есть 10 документов, возвращенных из этапа FETCH?
- Каковы будут последствия этого дополнительного этапа? Учитывая, что мне нужна нумерация страниц, следует ли мне придерживаться индексов варианта 1 и не использовать последний составной индекс?
