Le rôle de l'index de base de données

Le rôle le plus important d'un index de base de données est d'accélérer les requêtes. Il peut fondamentalement réduire le nombre de lignes d'enregistrement qui doivent être analysées. L'index de base de données est la structure des données de la base de données. stocke toutes les valeurs d'une colonne dans la table, c'est-à-dire que l'index est créé en fonction d'une colonne dans la table de données.

L'index de base de données est un identifiant attaché aux champs de la table afin d'augmenter la vitesse des requêtes. J'ai vu de nombreuses personnes comprendre le concept d'index de manière mécanique et penser que l'ajout d'index n'a que des avantages et aucun mal. Ici, je voudrais résumer les notes d'étude d'index précédentes :

Tout d'abord, comprenez pourquoi l'index augmentera la vitesse. Lorsque la base de données exécute une instruction SQL, la méthode par défaut consiste à effectuer une analyse complète de la table. sur les conditions de recherche. Lorsqu'une condition correspondante est rencontrée, elle est ajoutée à la collection de résultats de recherche. Si nous ajoutons un index à un certain champ, lors de l'interrogation, nous localiserons d'abord le nombre de lignes avec une valeur spécifique dans la liste d'index, ce qui réduit considérablement le nombre de lignes correspondantes parcourues, de sorte que la vitesse de requête peut être considérablement augmentée. Alors, faut-il ajouter l’indexation à tout moment ? Voici quelques contre-exemples : 1. Si vous avez besoin d'obtenir tous les enregistrements de la table à chaque fois, et que vous devez de toute façon effectuer une analyse complète de la table, alors cela ne sert à rien d'ajouter un index. 2. Pour les champs non uniques, tels que « sexe », qui comportent un grand nombre de valeurs répétées, l'ajout d'index n'a aucun sens. 3. Pour les tables avec relativement peu d'enregistrements, l'ajout d'index n'apportera pas d'optimisation de la vitesse mais gaspillera de l'espace de stockage, car les index nécessitent de l'espace de stockage, et il y a un inconvénient fatal que pour chaque exécution de mise à jour/insertion/suppression, le champ Tous les index doivent être recalculé pour les mises à jour.

Alors, quand est-il approprié d'ajouter un index ? Regardons un exemple donné dans le manuel Mysql. Voici une instruction SQL :

SELECT c.companyID, c.companyName FROM Companies c, User u WHERE c.companyID = u.fk_companyID AND c.numEmployees >. ; = 0 AND c.companyName LIKE '%i%' AND u.groupID IN (SELECT g.groupID FROM Groups g WHERE g.groupLabel = 'Executive')

Cette instruction implique la jointure de 3 tables. Et comprend de nombreuses conditions de recherche telles que la comparaison des tailles, la correspondance, etc. Le nombre de lignes d'analyse que Mysql doit effectuer sans index est de 77721876 lignes. Après avoir ajouté des index aux champs companyID et groupLabel, le nombre de lignes analysées n'est que de 134. Dans MySQL, vous pouvez afficher le nombre d'analyses via Explain Select. On constate que dans le cas de telles tables jointes et de conditions de recherche complexes, l'amélioration des performances apportée par l'index est bien plus importante que l'espace disque qu'il occupe.

Alors, comment est mis en œuvre l’index ? La plupart des fournisseurs de bases de données implémentent des index basés sur une structure de données - B-tree. Car la particularité de B-tree est qu'il est adapté à l'organisation de tables de recherche dynamique sur des périphériques de stockage direct tels que des disques. La définition de B-tree est la suivante : Un B-tree d'ordre m(m>=3) est un arbre m-aire qui satisfait les conditions suivantes :

1. Chaque nœud comprend la portée suivante ( j, p0 , k1, p1, k2, p2, ... ki, pi) où j est le nombre de mots-clés, p est le pointeur enfant

2. Tous les nœuds feuilles sont sur le même calque, et le nombre de couches est égal à la hauteur de l'arbre h

3. Le nombre de mots-clés contenus dans chaque nœud non racine satisfait à [m/2-1]<=j<=m-1

4. Si l'arbre n'est pas vide, alors la racine a au moins 1 mot-clé. Si la racine n'est pas une feuille, il y a au moins 2 sous-arbres et au plus m sous-arbres

Regardez. un exemple de B-tree Pour un B-tree avec 26 lettres anglaises, cela peut être fait Construction :

On peut voir que la complexité de la recherche de lettres anglaises dans cet arbre B n'est que de O(m). Lorsque la quantité de données est relativement importante, une telle structure peut augmenter considérablement la vitesse de requête. Cependant, il existe une autre structure de données qui exécute les requêtes plus rapidement que les arbres B : les tables de hachage. La définition de la table de hachage est la suivante : Soit u l'ensemble de tous les mots-clés possibles, les mots-clés réellement stockés sont notés k et |k| est beaucoup plus petit que |u|. La méthode de hachage consiste à mapper u à l'indice de la table T[0,m-1] via la fonction de hachage h, de sorte que les mots-clés dans u soient des variables et que le résultat de l'opération de fonction avec h soit l'adresse de stockage de le nœud correspondant. Ainsi, la recherche peut être terminée en un temps O(1).
Cependant, la table de hachage a un défaut, c'est-à-dire un conflit de hachage, c'est-à-dire que deux mots-clés calculent le même résultat via la fonction de hachage. Soit m et n représentant respectivement la longueur de la table de hachage et le nombre de nœuds remplis n/m est le facteur de remplissage de la table de hachage. Plus le facteur est grand, plus le risque de conflit de hachage est grand.
En raison de cette faille, la base de données n'utilisera pas les tables de hachage comme implémentation par défaut des index. Mysql prétend qu'il essaiera de convertir l'index B-tree basé sur le disque en un index de hachage approprié en fonction du format de requête d'exécution dans. afin de poursuivre les progrès. Améliorer la vitesse de recherche. Je pense que d'autres fournisseurs de bases de données auront des stratégies similaires. Après tout, sur le champ de bataille des bases de données, la vitesse de recherche et la sécurité de la gestion sont des points de concurrence très importants.

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!