но при выборке, какие-то поля могут отсутствовать (1-е всегда будет, остальные 4 по ситуации, порядок полей в запросе известен)
Прочитал много инфы, но так к верному решению и не пришел...
При выборке главное наличие 1-го поля, что бы индекс использовался (он у меня как раз всегда есть), а дальше, если отсутствует к примеру 3-е поле, то индекс так же будет использоваться? Просто выборка будет последовательно по 1, 2, 4 и 5 полю, без 3-го, либо только по 1 и 2, а поскольку 3-го нет, то и до 4-5 не дойдет?
составной поможет только при порядке тех полей что в нем, то есть для индекса a:1 b:1 c:1 d:1 будет ускорен только поиск: - a - a, b - a, b, c - a , b, c, d порядок важен, запрос типа find({b: 1, a:2}) не будет ускорен
т.е. если индекс a:1 b:1 c:1 d:1 а запрос у меня find({a: 1, c:2, d:1}) (без b), индекс не будет нормально отрабатывать и для такого запроса потребуется индекс типа a:1 c:1 d:1
порядок появления ключей в запросе не имеет значения, даже хз откуда эта информация у вас. А вот порядок ключей сортировки как раз влияет на факт участия индекса
скорее всего будет быстрее чем без индекса. Так же можно немного хитрить и в услвоие выборки указывать явно поле b но указывать ему для значения границы через $gt/$lt таким образом подталкивая планировщик использовать конкретный индекс индекс из этих четырех полей
интересная хитрость но немного не понял с реализацией т.е. если какое-то поле отсутствует, мы все равно дописываем его в запрос, но без конкретного значения, но это как сделать
db.getCollection('t_1').find({ a: 1, b: {$gte: MinKey}, b: {$lte: MaxKey}, c: 3 }).explain() хотя по идее достаточно либо мин либо макс, т.к. полностью покрывает Сейчас поигравшись кажется что всетаки это не очень идея и требует проверки на большом объеме данных а не на паре доков как у меня. Так что считайте рекомендацию сомнительной)
Не всегда это хорошая идея. Если большой объём выборки, то работает медленнее.
вот и я об этом подумал, что форсировать индекс может быть плохой идеей и планировщику виднее
Обсуждают сегодня