Изучение эфективности запросов, занимаемой памати и другое

Изучение того как был обработан запрос

для этого есть метод курсора .explain(), он выводит следующие пункты:

cursor - если поиск прошел без использования индекса мы увидим DefaultCursor, если с индексом, то мы увидим что-нибудь вроде "BtreeCursor indexfield1_1_indexfield2_1_...indexfieldN_1"

isMultyKey - тру, если в ключ входит поле со значением массива.

n - количество документов, которые вернулись в результате запроса.

nscannedObjects - количество просканированных документов для получения результата запроса.

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

indexOnly - может ли запрос быть удовлетворен только идексом

indexBounds - если у нас поиск идексный, то для каждого поля индекса(для сборного их несколько, для несборного - один) показываются границы сколько минимально может быть просканировано индексов, и сколько максимально -- пока не понятно как это я видет эти два значения равными???

millis - время выполнения запроса в милисекундах.


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

< db.foo.ensureIndex({a:1, b:1, c:1})

< db.foo.find({a:3})
< db.foo.find({c:1}).sort({a:1, b:1})

Но не:

< db.foo.find({b:3, c:4})
< db.foo.find({c:1}).sort({a:-1, b:1})

Как узнать размер

Размер колекции на диске:

< db.collection.stats()

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

< db.foo.totalIndexSize()

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