Като цяло ще искате да поставите индекс на полетата, използвани най-често като критерии за филтриране във вашите най-важни/чести заявки, като първо започнете с най-селективните полета. Има доста прилични насоки по темата като част от документацията на MongoDB
. Едно твърдение от особен интерес за вашия случай вероятно е това, тъй като имате много $or s:
Най-важното нещо тук обаче е да измервате, измервате, измервате и разглеждате плановете за изпълнение на заявки с помощта на explain() . Причината е, че най-вероятно ще имате различни видове заявки, които вашето приложение трябва да поддържа, и ще трябва да направите компромис в даден момент, когато трябва да избирате между разходите за поддръжка на индекса (напр. заключвания за запис по време на актуализации на индекси и изисквания за дисково пространство) и теоретично най-бързото решение, при което всички полета, използвани в една заявка, се покриват от един индекс.
Цялата тази тема за индексиране е малко неясна, което силно зависи от точния ви сценарий:
- Данните ви силно ли се актуализират и записите трябва ли да са супер бързи (ще искате по-малко/по-малки индекси) или вашите данни са доста стабилни с чести четения, които трябва да бъдат бързи (използвайте повече/по-големи индекси)?
- Какви видове заявки трябва да поддържате? Доколко си приличат по отношение на филтрите си? Определени комбинации от филтри ще бъдат ли по-вероятни от други? Кои заявки трябва да се представят добре, кои могат да бъдат малко по-бавни?
- Как се разпределят данните във вашите потенциално индексирани полета?
- и така нататък...
Няма да намерите единствения индекс, който помага на всички ваши заявки да се представят най-добре. И също така, когато добавяте повече индекси или променяте съществуващите, това може да накара оптимизатора на заявки да спре да използва някои индекси за някои заявки и вместо това да избере различен план за изпълнение, който може или не може да е желан. Така че измервайте всичко, което е важно при всяка промяна на вашето индексиране или оформление на физически данни (хардуерна настройка, шардинг...). И накрая, трябва редовно да измервате ефективността на вашите заявки, тъй като количеството ви данни расте, освен ако не е предвидимо равномерно в разпределението си.
Накратко:изберете итеративен подход и започнете с добавяне на индекс (бих предложил да добавите такъв на isBlockedByAdmin , isDelete и information.shares.userId ), след това измерете ефективността на вашата заявка и след това прецизирайте индекса си въз основа на констатациите си (и отново, и отново, ...).
