En general, deseará colocar un índice en los campos más utilizados como criterio de filtro en sus consultas más importantes/frecuentes, comenzando primero con los campos más selectivos. Hay bastantes orientaciones sobre el tema como parte de la documentación de MongoDB
. . Una declaración de particular interés para su caso es probablemente esta, ya que tiene mucho $or s:
Sin embargo, lo más importante aquí es medir, medir, medir y ver los planes de ejecución de consultas usando explicar() . La razón es que lo más probable es que tenga diferentes tipos de consultas que su aplicación necesita admitir y tendrá que hacer una compensación en algún momento en el que tenga que elegir entre los costos de mantenimiento del índice (por ejemplo, bloqueos de escritura durante las actualizaciones del índice y los requisitos de espacio en disco) y la solución teóricamente más rápida donde todos los campos utilizados en una sola consulta están cubiertos por un solo índice.
Todo ese tema de indexación es un poco confuso y depende en gran medida de su escenario preciso:
- ¿Sus datos están muy actualizados y las escrituras deben ser súper rápidas (querrá menos índices o más pequeños) o sus datos son bastante estables con lecturas frecuentes que deben ser rápidas (ir con más índices o más grandes)?
- ¿Qué tipos de consultas necesita admitir? ¿Qué tan similares son en términos de sus filtros? ¿Ciertas combinaciones de filtros serán más probables que otras? ¿Qué consultas deben funcionar bien, cuáles pueden ser un poco más lentas?
- ¿Cómo se distribuyen los datos en sus campos potencialmente indexados?
- y así sucesivamente...
No encontrará el índice único que ayude a que todas sus consultas funcionen de la mejor manera. Y también, al agregar más índices o cambiar los existentes, esto puede causar que el optimizador de consultas deje de usar algún índice para algunas consultas y elija un plan de ejecución diferente que puede o no ser deseado. Así que mida todo lo que es importante sobre cualquier cambio en su indexación o diseño de datos físicos (configuración de hardware, fragmentación...). Por último, debe medir el rendimiento de sus consultas con regularidad a medida que crece la cantidad de datos, a menos que sea previsiblemente uniforme en su distribución.
Para acortar una larga historia:opte por un enfoque iterativo y comience agregando un índice (sugeriría agregar uno en isBlockedByAdmin , isDelete y information.shares.userId ) luego mida el rendimiento de su consulta y luego refine su índice en función de sus hallazgos (y una y otra vez, ...).
