Obecně budete chtít umístit index na pole, která se nejčastěji používají jako kritéria filtru ve vašich nejdůležitějších/nejčastějších dotazech, počínaje nejselektivnějšími poli jako první. Existuje docela slušný návod k tématu jako součást dokumentace MongoDB
. Jedno prohlášení, které je pro váš případ obzvláště zajímavé, je pravděpodobně toto, protože máte hodně $or s:
Nejdůležitější je zde však měřit, měřit, měřit a dívat se na plány provádění dotazů pomocí explain() . Důvodem je to, že s největší pravděpodobností budete mít různé druhy dotazů, které vaše aplikace potřebuje podporovat, a v určitém okamžiku, kdy si budete muset vybrat mezi náklady na údržbu indexu, budete muset udělat kompromis (např. zámky zápisu během aktualizací indexu a požadavků na místo na disku) a teoreticky nejrychlejší řešení, kde jsou všechna pole použitá v jediném dotazu pokryta jedním indexem.
Celé toto téma indexování je trochu nejasné, což silně závisí na vašem přesném scénáři:
- Jsou vaše data intenzivně aktualizována a zápisy musí být superrychlé (budete chtít méně/menší indexy) nebo jsou vaše data poměrně stabilní s častým čtením, které musí být rychlé (použijte více/větší indexy)?
- Jaké druhy dotazů potřebujete podporovat? Jak moc jsou si podobné, pokud jde o jejich filtry? Budou určité kombinace filtrů pravděpodobnější než jiné? Které dotazy musí fungovat dobře a které mohou být o něco pomalejší?
- Jak jsou distribuována data ve vašich potenciálně indexovaných polích?
- a tak dále...
Nenajdete jediný index, který pomáhá všem vašim dotazům podávat nejlepší výkon. A také při přidávání dalších indexů nebo změně existujících to může způsobit, že optimalizátor dotazů přestane pro některé dotazy používat nějaký index a místo toho zvolí jiný plán provádění, který může nebo nemusí být žádoucí. Změřte tedy vše, co je důležité při jakékoli změně indexování nebo rozložení fyzických dat (nastavení hardwaru, sharding...). A konečně, měli byste pravidelně měřit výkon dotazu s rostoucím množstvím dat, pokud není distribuce předvídatelně jednotná.
Abych to zkrátil:Použijte iterativní přístup a začněte přidáním indexu (doporučuji přidat jeden na isBlockedByAdmin , isDelete a information.shares.userId ) poté změřte výkon dotazu a poté zpřesněte svůj index na základě vašich zjištění (a znovu a znovu, ...).