Qu'est-ce qu'un index?
Dans mysql, un index est une structure de données qui aide mysql à trouver rapidement certaines données. Il est trié et indépendant des données de la table mysql.
Quel type de structure de données d'index est divisé en
Arbre binaire, arbre rouge-noir, table de hachage, arbre B.
Ici, nous introduisons principalement la table de hachage et l'arbre B
Table de hachage
Quelle est hachage de
hachage est une sorte de fonction de hachage, en mettant en correspondance la valeur d'entrée à une valeur, par exemple: table de hachage (100) = 1, différents algorithmes de hachage, la valeur après le hachage peut être différent.
La table de hachage existe dans mysql sous la forme de mappage de données, alors comment la table de hachage est-elle générée?
Lors de l'ajout d'un élément de données à la table, commencez par hacher la clé primaire, puis établissez une relation de mappage entre l'adresse des données et la valeur de hachage. Lorsque nous recherchons ces données en fonction de la clé primaire, il suffit de hacher la clé primaire, obtenez la valeur de hachage et enfin, recherchez les données directement en fonction de la valeur de hachage. Par conséquent, l'algorithme de hachage n'a besoin d'exécuter qu'une seule fois les E / S de disque et la vitesse de requête est très rapide.
BTree
L'arbre B est également appelé arbre multi-fourches. Il est divisé en plusieurs fourches sur la base de l'arbre binaire. Regardons son diagramme de structure de données.
Nous pouvons voir sur la figure que l'arbre B a ces caractéristiques:
1. Les nœuds sont triés par ordre croissant de gauche à droite
2. Chaque nœud de données sera suivi d'un pointeur qui pointe vers l'adresse mémoire du niveau suivant. Le niveau suivant fait référence à l'adresse dans la mémoire où se trouve l'enregistrement de données situé entre les valeurs sur les côtés gauche et droit du pointeur actuel.
3. Le pointeur du nœud feuille est vide
4. Tous les éléments d'index ne sont pas répétés.
5. Chaque nœud d'index stocke les données d'enregistrement actuellement pointées (ou l'adresse mémoire)
Arbre B +
L'arbre B + est en fait une variante de l'arbre B. Il a apporté quelques améliorations sur la base de l'arbre B. Tous les enregistrements de données associés au nœud d'index sont déplacés vers les nœuds feuilles. Le but est de stocker plus de nœuds d'index. Mais cela augmente la redondance du nœud d'index, car le nœud feuille contient tous les nœuds d'index.
Comme le montre la figure, l'arborescence B + présente les caractéristiques suivantes:
1. Les nœuds feuilles contiennent tous les nœuds d'index
2. Les nœuds non-feuilles ne stockent pas les enregistrements de données
3. Utilisez des connexions de pointeur entre les nœuds feuilles pour améliorer la commodité de l'accès par intervalles
4. Le nœud d'index le plus à gauche pointé par le pointeur est une valeur supérieure ou égale au côté gauche de la profondeur du pointeur.
Qu'est-ce qui est optimisé pour l'arbre b + de mysql?
Voyons à quoi ressemble l'arborescence B + dans mysql
1. Ajout d'un pointeur bidirectionnel
2. Le premier et le dernier nœuds sont également liés par des pointeurs Le
but principal est de prendre en charge la recherche de plage dans l'index plus convivial. Si nous n'ajoutons pas le pointeur de liste doublement liée, chaque fois que nous recherchons, nous devons retourner au nœud racine pour rechercher, ce qui augmente les E / S du disque et augmente le temps de requête.
Comment calculer la quantité maximale de données prise en charge par B + tree
Dans mysql, vous pouvez utiliser la SHOW GLOBAL STATUS LIKE 'Innodb_page_size%'commande pour trouver le paramètre mysql de la taille de la page du nœud d'index. La taille de ce paramètre détermine le nombre d'index que nous pouvons charger à partir du disque à la fois.
Dans la version 5.7, Innodb_page_size est défini par défaut sur 16384, soit 16k.
Nous calculons maintenant combien de données peuvent être prises en charge dans myssql si le moteur de stockage est innodb?
Nous calculons selon un arbre d'une hauteur de 3:
1. Selon le stockage de champ de chaque type de données bigint, chaque nœud d'index non-feuille a besoin d'au plus 8B
2. En plus du pointeur connecté après chaque nœud d'index, la taille du pointeur défini dans innodb est 6B
3. Ajoutez le deux Un total de 14B, de sorte que le nœud de premier niveau peut stocker un total de 16kB / 14B = 1170 nœuds d'index
. 4. Les nœuds de deuxième niveau sont séparés des nœuds de premier niveau, c'est-à-dire que chaque nœud du premier Les nœuds de niveau peuvent être divisés en 1170, de sorte qu'un total de 1170 1170 = 1368900 nœuds d'index
peut être stocké dans le nœud secondaire et le nœud principal . 5. Le nœud de troisième niveau est également le nœud feuille. Le nœud feuille stocke la valeur de la clé primaire + les données d'enregistrement. Les données d'enregistrement peuvent atteindre 1 Ko. À ce stade, la valeur de clé primaire 8B peut être ignorée, de sorte que chaque nœud feuille peut stocker jusqu'à 16k / 1k = 16 enregistrements. 6. Ainsi, la table de la structure du moteur Innodb peut prendre en charge jusqu'à 1170 1170 * 16 = 21902400 données, soit environ 2,1 milliards. Si elle est supérieure à cette valeur, il faut en fait une sous-base de données et une table, MySQL recommande que la profondeur du L'arbre B + doit être inférieur à 3.
''
L'algorithme de hachage est rapide, pourquoi MySQL utilise-t-il rarement les index de hachage?
Comme mentionné ci-dessus, l'algorithme de hachage n'a besoin d'exécuter une E / S disque qu'une seule fois lors de la recherche de données, et la vitesse de requête est très rapide, mais pourquoi mysql n'est-il pas recommandé? Il y a principalement les raisons suivantes:
1. Conflit de hachage (la proportion est faible, car la qualité de l'algorithme de hachage de mysql est relativement élevée et la probabilité de conflit de hachage est relativement faible)
2. La requête de plage ne peut pas être effectuée (car la valeur de hachage est stocké dans la table de hachage, pas dans les données elles-mêmes, il est donc impossible de comparer les données. Si vous êtes sûr que votre table ne sera utilisée que pour une recherche précise, vous pouvez utiliser l'index de la structure de hachage)
Quelle est la différence entre l'arbre B et l'arbre B +?
1. Une liste doublement liée est ajoutée pour faciliter la recherche par plage
2. Seuls les nœuds feuilles stockent les enregistrements de données, ce qui signifie que plus de nœuds d'index peuvent être stockés.
Quelle est la différence entre un index clusterisé (clusterisé) et un index non clusterisé (clusterisé)?
Index en cluster (en cluster): les fichiers d'index et les fichiers de données sont stockés ensemble.
Index non en cluster (en cluster): les fichiers d'index et les fichiers de données sont stockés séparément
Implémentation du moteur de stockage Innodb (clé primaire et clé secondaire)
Index de clé primaire: le
type d'arborescence B + est utilisé par défaut dans InnoDB, qui stocke l'index clusterisé. La zone de données du nœud feuille stocke l'intégralité de l'enregistrement associé à la clé primaire actuelle.
Clé secondaire:
la zone de données de La clé secondaire stocke la valeur de la clé primaire. Autrement dit, si vous utilisez la requête d'index de clé secondaire, vous devez enfin trouver l'enregistrement correspondant par la valeur de la clé primaire.
L'index du moteur de stockage myisam, indépendamment de la clé primaire ou de l'index auxiliaire, la zone de données enregistre l'adresse mémoire des données associées, car myisam est un index non clusterisé, le fichier d'index et le fichier de données sont stockés séparément.
Pourquoi les tables Innodb doivent-elles avoir des clés primaires? Et il est recommandé d'utiliser un entier et d'incrémenter automatiquement la clé primaire?
1. Pourquoi la table Innodb doit-elle avoir une clé primaire?
Dans la table du moteur de stockage innodb, mysql ajoutera un index cluster à la clé primaire. S'il n'y a pas de clé primaire, mysql choisira le champ avec l'index unique dans le table d'élection comme clé primaire et créer l'index de clé primaire;
si la table est Si aucun champ n'est défini comme un index unique, mysql générera un row_id comme clé primaire pour créer un index de clé primaire.
2. Pourquoi mysql recommande-t-il d'utiliser le plastique comme type de champ de clé primaire?
Lors de la construction de l'arbre B, mysql sera construit dans l'ordre de petit à grand. S'il s'agit d'un nombre entier, mysql peut le comparer directement. S'il s'agit d'un autre type, mysql doit également convertir la valeur en code ascill pour comparaison., Cela augmentera le temps de création des index et des requêtes.
3. Pourquoi l'exigence est-elle de type auto-incrémenté?
Ceci est déterminé par les restrictions de mysql:
1. mysql définit la taille de la page de lecture unique d'innodb en mémoire à 16384B, c'est-à-dire que la taille maximale de chaque nœud est 16k,
2. btree est arrangé dans l'ordre de gauche à droite;
Si la clé primaire n'augmente pas automatiquement, si une nouvelle valeur de 11 est ajoutée à ce moment, alors après la comparaison, 11 doit être stocké entre 10 et 12:
1. Si le nœud est déjà 16k à ce moment, ajoutez it again Si une donnée dépasse la limite fixée par mysql, elle sera divisée en deux nœuds Cette opération augmentera également le temps de création de l'index.
2. S'il est réglé sur auto-incrémentation en fonction du champ, les données plus petites que le numéro de série actuel ne seront pas insérées, continuez simplement à développer sur le côté droit et il n'y aura pas de fractionnement de nœud.
Pourquoi les nœuds feuilles de la structure d'index de clé non primaire stockent la valeur de la clé primaire (cohérence et espace de stockage)
1. Si vous stockez des données spécifiques, cela entraînera une incohérence des données, car l'index de clé primaire et l'index auxiliaire conserveront les enregistrements de données en même temps. Si l'une des opérations de maintenance échoue, il y aura des incohérences.
2. Si les deux données spécifiques sont stockés, cela entraînera une perte d'espace de stockage. Si vous ne stockez que les enregistrements de clé primaire, vous pouvez stocker plus d'enregistrements d'index, mais vous devez trouver des données spécifiques basées sur la clé primaire deux fois pour échanger de l'espace avec le temps
La structure de stockage sous-jacente de l'index conjoint
Une recherche sur WeChat. middleware, etc. Les informations vous attendent.
Plus vous lirez de livres sans réfléchir, vous sentirez que vous en savez beaucoup; et plus vous lirez et réfléchirez, plus vous verrez clairement que vous en savez très peu. --Voltaire