Quelle est la différence entre l'index B-Tree et l'index Hash dans MySQL ?

La différence entre l'index B-Tree et l'index Hash dans MySQL : 1. L'index B-Tree prend en charge le principe de correspondance de préfixe le plus à gauche, mais l'index Hash ne le prend pas en charge 2. MyISAM et InnoDB prennent en charge B-Tree ; index, tandis que l'index de hachage n'est pris en charge que par les index du moteur Memory et NDB.

Indice de hachage

La particularité de la structure de l'indice de hachage, son efficacité de récupération est très élevée, et l'indice peut être récupéré une fois positionné, contrairement à l'index B-Tree, qui nécessite plusieurs accès IO du nœud racine au nœud de branche, et enfin au nœud de page, de sorte que l'efficacité des requêtes de l'index Hash est bien supérieure à celle du B -Indice d'arbre.

Beaucoup de gens peuvent encore avoir des questions. Puisque l'index Hash est beaucoup plus efficace que B-Tree, pourquoi tout le monde n'utilise-t-il pas l'index Hash mais utilise également l'index B-Tree ? Tout a deux faces, et il en va de même pour les index Hash. Bien que les index Hash soient très efficaces, les index Hash eux-mêmes présentent également de nombreuses limitations et inconvénients en raison de leur particularité, principalement les suivants.

(1) L'index de hachage ne peut satisfaire que les requêtes "=", "IN" et "<=>", et les requêtes par plage ne peuvent pas être utilisées.

Étant donné que l'index de hachage compare la valeur de hachage après l'opération de hachage, il ne peut être utilisé que pour un filtrage de valeurs égales et ne peut pas être utilisé pour un filtrage basé sur la plage, car la valeur de hachage après traitement par l'algorithme de hachage correspondant. Il n'est pas garanti que la relation soit exactement la même qu'avant l'opération de hachage.

(2) L'index de hachage ne peut pas être utilisé pour éviter les opérations de tri des données.

Étant donné que l'index de hachage stocke la valeur de hachage après le calcul du hachage et que la relation de taille de la valeur de hachage n'est pas nécessairement exactement la même que la valeur de clé avant l'opération de hachage, la base de données ne peut donc pas utiliser les données d'index pour éviter toute opération de tri ;

(3) L'index de hachage ne peut pas être interrogé à l'aide de clés d'index partiel.

Pour l'index combiné, lors du calcul de la valeur de hachage de l'index de hachage, les clés d'index combinées sont fusionnées puis la valeur de hachage est calculée ensemble, au lieu de calculer la valeur de hachage séparément, donc la ou plusieurs précédentes les clés d'index de l'index combiné sont utilisées pour calculer la valeur de hachage Lors de l'interrogation, l'index de hachage ne peut pas être utilisé.

(4) L'index de hachage ne peut à aucun moment éviter l'analyse de la table.

Comme nous le savons auparavant, l'index de hachage consiste à stocker la valeur de hachage du résultat de l'opération de hachage et les informations de pointeur de ligne correspondantes dans une table de hachage après que l'opération de hachage est effectuée sur la clé d'index, car différentes clés d'index ont le. même valeur de hachage, donc même si vous obtenez le nombre d'enregistrements qui satisfont à une certaine valeur de clé de hachage, vous ne pouvez pas terminer directement la requête à partir de l'index de hachage. Vous devez toujours effectuer les comparaisons correspondantes en accédant aux données réelles de la table et obtenir le. résultats correspondants.

(5) Lorsqu'un index Hash rencontre un grand nombre de valeurs de hachage égales, ses performances ne seront pas nécessairement supérieures à celles de l'index B-Tree.

Pour les clés d'index à faible sélectivité, si vous créez un index de hachage, un grand nombre d'informations de pointeur d'enregistrement seront stockées dans la même valeur de hachage. De cette façon, il sera très difficile de localiser un certain enregistrement et cela gaspillera plusieurs accès aux données de la table, ce qui entraînera de faibles performances globales.

Index B-Tree

L'index B-Tree est le type d'index le plus fréquemment utilisé dans la base de données MySQL. Tous les autres moteurs de stockage, à l'exception du moteur de stockage Archive, prennent en charge B. -Index des arbres. Cela n'est pas seulement vrai dans MySQL, mais en fait, dans de nombreux autres systèmes de gestion de bases de données, l'index B-Tree est également le type d'index principal. Cela est principalement dû au fait que la structure de stockage de l'index B-Tree est très importante dans l'inspection des données. la base de données.>

Suozhong a de très bonnes performances.

De manière générale, la plupart des fichiers physiques de l'index B-Tree dans MySQL sont stockés dans la structure Balance Tree, c'est-à-dire que toutes les données réelles requises sont stockées dans le nœud feuille de l'arbre et peuvent être accessible n'importe où. La longueur du chemin le plus court d'un nœud feuille est exactement la même, c'est pourquoi nous l'appelons tous un index B-Tree. Bien sûr, diverses bases de données (ou divers moteurs de stockage de MySQL) peuvent stocker leurs propres index B-Tree. . La structure de stockage sera légèrement modifiée. Par exemple, la structure de stockage réelle utilisée par l'index B-Tree du moteur de stockage Innodb est en fait B+Tree, qui est une très petite modification basée sur la structure de données B-Tree dans chaque

Leaf Node. En plus de stocker les informations pertinentes de la clé d'index, les informations du pointeur pointant vers le prochain nœud feuille adjacent au nœud feuille sont également stockées. Ceci est principalement pour accélérer l'efficacité de la récupération de plusieurs nœuds feuilles adjacents.

Tutoriel recommandé : "

Tutoriel MySQL"

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!