Table des matières
1. Créer un index
1. Créer un index
> db.student.createIndex({
"name":1})
{
"numIndexesBefore" : 1,
"numIndexesAfter" : 2,
"createdCollectionAutomatically" : false,
"ok" : 1
}
2. Requête par index
> db.student.find({
"name":"哪吒"}).explain("executionStats"))
{
"explainVersion" : "1",
"queryPlanner" : {
"namespace" : "test.student",
"indexFilterSet" : false,
"parsedQuery" : {
"name" : {
"$eq" : "哪吒"
}
},
"maxIndexedOrSolutionsReached" : false,
"maxIndexedAndSolutionsReached" : false,
"maxScansToExplodeReached" : false,
"winningPlan" : {
"stage" : "FETCH",
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"name" : 1
},
"indexName" : "name_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"name" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"name" : [
"[\"哪吒\", \"哪吒\"]"
]
}
}
},
"rejectedPlans" : [ ]
},
"executionStats" : {
"executionSuccess" : true,
"nReturned" : 0,
"executionTimeMillis" : 16,
"totalKeysExamined" : 0,
"totalDocsExamined" : 0,
"executionStages" : {
"stage" : "FETCH",
"nReturned" : 0,
"executionTimeMillisEstimate" : 13,
"works" : 1,
"advanced" : 0,
"needTime" : 0,
"needYield" : 0,
"saveState" : 0,
"restoreState" : 0,
"isEOF" : 1,
"docsExamined" : 0,
"alreadyHasObj" : 0,
"inputStage" : {
"stage" : "IXSCAN",
"nReturned" : 0,
"executionTimeMillisEstimate" : 13,
"works" : 1,
"advanced" : 0,
"needTime" : 0,
"needYield" : 0,
"saveState" : 0,
"restoreState" : 0,
"isEOF" : 1,
"keyPattern" : {
"name" : 1
},
"indexName" : "name_1",
"isMultiKey" : false,
"multiKeyPaths" : {
"name" : [ ]
},
"isUnique" : false,
"isSparse" : false,
"isPartial" : false,
"indexVersion" : 2,
"direction" : "forward",
"indexBounds" : {
"name" : [
"[\"哪吒\", \"哪吒\"]"
]
},
"keysExamined" : 0,
"seeks" : 1,
"dupsTested" : 0,
"dupsDropped" : 0
}
}
},
"command" : {
"find" : "student",
"filter" : {
"name" : "哪吒"
},
"$db" : "test"
},
"serverInfo" : {
"host" : "DESKTOP-HU0H0AI",
"port" : 27017,
"version" : "5.0.14",
"gitVersion" : "1b3b0073a0b436a8a502b612f24fb2bd572772e5"
},
"serverParameters" : {
"internalQueryFacetBufferSizeBytes" : 104857600,
"internalQueryFacetMaxOutputDocSizeBytes" : 104857600,
"internalLookupStageIntermediateDocumentMaxSizeBytes" : 104857600,
"internalDocumentSourceGroupMaxMemoryBytes" : 104857600,
"internalQueryMaxBlockingSortMemoryUsageBytes" : 104857600,
"internalQueryProhibitBlockingMergeOnMongoS" : 0,
"internalQueryMaxAddToSetBytes" : 104857600,
"internalDocumentSourceSetWindowFieldsMaxMemoryBytes" : 104857600
},
"ok" : 1
}
Une liste de significations renvoyées par expliquer() :
queryPlanner (plan de requête) : les détails du plan sélectionné par l'optimisation de la requête et le plan rejeté. Il peut contenir les valeurs suivantes :
queryPlanner.namespace - une chaîne spécifiant l'espace de noms pour exécuter la requête
queryPlanner.indexFilterSet - un booléen indiquant si MongoDB utilise ou non le filtrage d'index dans les requêtes
queryPlanner.winningPlan - le document de plan winnerPlan choisi par l'optimiseur de requête. stage - la chaîne représentant l'étape
de la
requête
. statut d'exécution) : rejeté Description détaillée des plans d'exécution sélectionnés et des plans d'exécution rejetés :
queryPlanner.nReturned - nombre de documents correspondant aux conditions de la requête
queryPlanner.executionTimeMillis - temps total requis pour la sélection du plan et l'exécution de la requête (en millisecondes)
queryPlanner.totalKeysExamined - nombre total de index analysés par
queryPlanner.totalDocsExamined - nombre total de documents
analysés queryPlanner.totalDocsExamined - nombre total de documents analysés
queryPlanner.executionStages - arborescence des étapes de la requête montrant les détails de la réussite de
l'exécution executionStages.works - spécifie le nombre "d'unités de travail" exécutées par l'étape d'exécution de la requête
executionStages.advanced - le nombre de résultats intermédiaires renvoyés executionStages.needTime - le nombre
de cycles de travail qui n'ont pas avancé les résultats intermédiaires vers leur parent
executionStages.needYield - le nombre de fois que la couche de stockage a demandé des verrous générés par le système de requête
executionStages. isEOF - spécifie si l'étape d'exécution a été atteinte à la fin du flux
queryPlanner.allPlansExecution - Contient des informations d'exécution partielles capturées pendant la phase de sélection du plan, y compris les plans sélectionnés et rejetés
serverInfo, (informations sur le serveur) : informations sur l'instance MongoDB : serverInfo.winningPlan - le plan d'exécution a
utilisé winnerPlan.shards - inclut un tableau de documents pour queryPlanner et serverInfo pour chaque tranche d'accès
Les index peuvent réduire considérablement le temps de requête. Cependant, l'utilisation des index a un prix. L'ajout, la suppression et la modification des champs d'index prendront plus de temps, car lors de la modification des données, MongoDB doit également mettre à jour l'index en plus de la mise à jour des données du document. C'est la même chose que les bases de données relationnelles. Le mécanisme d'indexation de MongoDB est similaire à celui des bases de données relationnelles.
Pour choisir les champs à indexer, passez en revue les requêtes courantes et celles qui doivent être exécutées rapidement.
2. Indice composite
Il est nécessaire de créer un index sur deux clés ou plus, et l'index conservera toutes ses valeurs dans l'ordre, donc le tri des documents par clé d'index est beaucoup plus rapide.
> db.student.createIndex({
"name":1,"age":1}) ")
{
"numIndexesBefore" : 2,
"numIndexesAfter" : 3,
"createdCollectionAutomatically" : false,
"ok" : 1
}
Les index conformes permettent à MongoDB d'exécuter efficacement des requêtes avec plusieurs clauses. Lors de la conception d'un index basé sur plusieurs champs, le champ utilisé pour la correspondance exacte doit être placé en premier et le champ utilisé pour la correspondance de plage doit être placé en dernier. De cette manière, la première clé d'index peut être utilisée pour une correspondance exacte, puis la deuxième plage d'index peut être utilisée pour rechercher dans l'ensemble de résultats.
3. Indexer les documents intégrés
MongoDB permet d'explorer les documents pour créer des index sur des champs et des tableaux intégrés. Les champs d'objet et de tableau incorporés peuvent être utilisés avec des champs de niveau supérieur dans des index conformes.
Les index peuvent être créés sur les clés des documents intégrés de la même manière que sur les clés normales.
Créez un index sur le champ d'adresse dans info. Créez un index sur le sous-document et l'optimiseur de requête ne pourra utiliser "address"l'index sur le sous-document que lorsque la requête correspond exactement à l'ordre des champs dans le sous-document.
> db.teacher.find() 新园区"}})
{
"_id" : ObjectId("638ca288e96330d24f819182"), "id" : "1", "name" : "哪吒编程", "info" : {
"id" : 1, "level" : "1", "address" : "大连市高新园区" } }
{
"_id" : ObjectId("638ca288e96330d24f819183"), "id" : "2", "name" : "云韵", "info" : {
"id" : 2, "level" : "1", "address" : "北京市" } }
{
"_id" : ObjectId("638ca288e96330d24f819184"), "id" : "3", "name" : "萧炎", "info" : {
"id" : 3, "level" : "2", "address" : "沈阳市青年大街" } }
{
"_id" : ObjectId("638ca289e96330d24f819185"), "id" : "4", "name" : "美杜莎", "info" : {
"id" : 4, "level" : "3", "address" : "上海市浦项道" } }
{
"_id" : ObjectId("638ca28ae96330d24f819186"), "id" : "5", "name" : "雅妃", "info" : {
"id" : 5, "level" : "2", "address" : "深圳市中山路" } }
> db.teacher.createIndex({
"info.address":1})
{
"numIndexesBefore" : 1,
"numIndexesAfter" : 2,
"createdCollectionAutomatically" : false,
"ok" : 1
}
4. Cardinalité de l'indice
La cardinalité fait référence au nombre de valeurs distinctes qu'un champ a dans une collection.
En général, plus la cardinalité d'un champ est élevée, plus un index sur ce champ sera utile. En effet, un tel index peut rapidement restreindre la recherche à un ensemble de résultats relativement petit. Pour les champs à faible cardinalité, les index sont généralement incapables d'exclure un grand nombre de correspondances possibles.
Cinq, explique
Pour les requêtes lentes, expliquer est l'un des outils de diagnostic les plus importants. Grâce à expliquer, vous pouvez comprendre quels index sont utilisés par la requête et comment ils sont utilisés. Pour toute requête, vous pouvez ajouter une explication à la fin pour l'analyse de la requête.
6. Pourquoi ne pas utiliser des index
Les index sont plus efficaces lors de la récupération de sous-ensembles de données plus petits, et certaines requêtes sont plus rapides sans index.
Plus la proportion du jeu de résultats dans la collection d'origine est grande, moins l'index sera efficace, car l'utilisation de l'index nécessite deux recherches : l'une consiste à rechercher l'élément d'index et l'autre à rechercher le document vers lequel il pointe. basé sur la zone de pointeur de l'index. Une analyse complète de la table, en revanche, ne nécessite qu'une seule recherche : le document de recherche. Dans le pire des cas (renvoyant tous les documents de la collection), les recherches utilisant l'index prendront deux fois plus de temps qu'un balayage complet de la table et seront généralement beaucoup plus lentes qu'un balayage complet de la table.
Sept, ensemble fixe
Pour une collection de taille fixe, lorsque nous insérons des données dans une collection fixe complète, le document le plus ancien du document est supprimé. La collection fixe n'autorise pas les opérations qui entraîneront une modification de la taille de la collection. Les documents de la collection fixe la collection peut être insérée Le stockage s'effectue de manière séquentielle et il n'est pas nécessaire de maintenir une liste libre d'espace pour les documents supprimés.
Contrairement à la plupart des collections dans MongoDB, le mode d'accès des collections fixes est que les données sont écrites séquentiellement dans un espace fixe du disque, ce qui les rend très rapides sur les disques durs mécaniques, surtout lorsque la collection possède un disque dédié.
De manière générale, pour les collections fixes, MongoDB préfère utiliser les index TTL car ils fonctionnent mieux dans le moteur de stockage WiredTiger. Les index TTL expirent en fonction de la valeur du champ de type de date et de la valeur TTL de l'index, et suppriment les données de la collection normale.
L'index TTL permet de définir un délai d'expiration pour chaque document, et lorsqu'un document atteint son délai d'expiration prédéfini, il sera supprimé. Pour empêcher la suppression d'une session active, le lastUpdatedchamp peut être mis à jour avec l'heure actuelle lorsqu'il y a une activité sur la session.
Résumé de la route d'apprentissage Java, les déménageurs de briques attaquent les architectes Java
Résumé de 100 000 mots et 208 questions d'entrevue classiques Java (avec réponses)
Série de didacticiels de base Java
Série de programmation Java à haute concurrence
Base de données Advanced Combat Series
.