classement de l'indice
par type
Indice normal - NORMAL
Les index ordinaires sont ceux qui sont souvent utilisés, y compris les index composites
Index unique - UNIQUE
valeur unique
Indexation de texte intégral - FULLTEXT
Uniquement pris en charge dans les versions 5.6 et ultérieures
Les index de texte intégral ne peuvent être créés que si le type de données du champ est char, varchar, text et sa série
La fonction de l'index de texte intégral est similaire à la recherche par plage de like. Dans le cas de like avec une grande quantité de données, c'est N fois plus rapide que like + %, mais il peut y avoir des problèmes de précision ;
Si une grande quantité de données doit être indexée en texte intégral, il est recommandé d'ajouter d'abord les données, puis de créer l'index ;
Pour le chinois, vous pouvez utiliser une version postérieure à MySQL 5.7.6 ou un plug-in tiers.
Index spatial - SPATIAL
Il s'agit d'un index établi pour les champs de types de données spatiales. Il existe quatre types de données spatiales dans MySQL, à savoir GEOMETRY, POINT, LINESTRING et POLYGON.
Ne peut être créé que dans des tables dont le moteur de stockage est MyISAM
Les 4 ci-dessus peuvent être vus lors de la création
index de clé primaire
Créé automatiquement lors de la création de la table
Classé par structure de stockage
Arbre B+
Hacher
Seul le moteur de mémoire prend explicitement en charge les recherches par hachage
Les hachages ne prennent en charge que les comparaisons d'égalité, pas les requêtes de plage. Une fois qu'il y a de nombreuses collisions de hachage, le coût de maintenance est très élevé. innoDB prend en charge "l'index de hachage adaptatif".
Vérifier si l'index est utilisé
En utilisant le mot-clé EXPLAIN, si la ligne possible_keys et la ligne de clé contiennent le champ year_publication, cela signifie que l'index est utilisé dans la requête.
identifiant
Le numéro de série de la requête de sélection, y compris un ensemble de nombres, indiquant l'ordre dans lequel la clause de sélection ou la table d'opérations est exécutée dans la requête
sélectionner le genre
Il sert principalement à distinguer le type de requête, qu'il s'agisse d'une requête normale, d'une requête conjointe ou d'une sous-requête
tableau
Quelle table, quel nom de table ou quel alias est accédé par la ligne correspondante, il peut s'agir d'une table temporaire ou d'un ensemble de résultats fusionnés par union
1. S'il s'agit d'un nom de table spécifique, cela signifie que les données sont obtenues à partir de la table physique réelle, bien sûr, il peut également s'agir d'un alias de la table
2. Le nom de la table est sous la forme dérivéeN, ce qui signifie que la table dérivée générée par la requête avec l'id N est utilisée
3. Lorsqu'il y a un résultat d'union, le nom de la table est sous la forme d'union n1, n2, etc., et n1 et n2 représentent les identifiants participant à l'union
taper
type montre le type d'accès, qui indique comment j'accède à nos données. La chose la plus facile à penser est une analyse complète de la table, traversant directement une table violemment pour trouver les données requises, l'efficacité est très faible et l'accès Il existe de nombreux types , par ordre d'efficacité du meilleur au pire :
**system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL **
En général, il faut s'assurer que la requête atteint au moins le niveau de la plage, et il est préférable d'atteindre la ref
clés_possibles
Quels index sont utilisés
clé
Index réellement utilisé. S'il est nul, l'index n'est pas utilisé. Si un index de couverture est utilisé dans la requête, l'index chevauche le champ de sélection de la requête.
key_len
Indique le nombre d'octets utilisés dans l'index. La longueur de l'index utilisé dans la requête peut être calculée via key_len. Plus la longueur est courte, mieux c'est sans perte de précision.
réf
Indique quelle colonne de l'index est utilisée, une constante si possible
Lignes
En fonction des informations statistiques de la table et de l'utilisation de l'index, estimez approximativement le nombre de lignes qui doivent être lues pour trouver les enregistrements requis. Ce paramètre est très important. Il reflète directement la quantité de données que le SQL trouve et la moins, mieux c'est, mieux c'est pour atteindre l'objectif.
supplémentaire
Contient des informations supplémentaires.
--using filesort : indique que mysql ne peut pas utiliser l'index pour le tri, mais ne peut utiliser que l'algorithme de tri pour le tri, ce qui consommera des positions supplémentaires
--using temporaire : créer une table temporaire pour enregistrer les résultats intermédiaires, supprimer la table temporaire une fois la requête terminée
--using index : Cela signifie que la requête actuelle couvre l'index et lit les données directement à partir de l'index sans accéder à la table de données. S'il y a une utilisation où l'index de nom de table est utilisé pour effectuer la recherche de la valeur de la clé d'index, sinon, cela indique que l'index est utilisé pour lire les données, pas la vraie recherche
--using where : utiliser where pour le filtrage conditionnel
--using join buffer : utilise le cache de connexion
--impossible where : le résultat de l'instruction where est toujours faux
Index clusterisés et non clusterisés
index clusterisé
Il ne s'agit pas d'un type d'index distinct, mais d'une méthode de stockage de données, qui fait référence au stockage compact des lignes de données et des index adjacents. C'est à stocker dans un fichier de données
Avantages 1. Les données sont dans un dossier 2. L'accès est rapide car il y a des données sur les nœuds feuilles 3. La requête utilisant le balayage de l'index de couverture peut utiliser directement la valeur de la clé primaire dans le nœud de la page
Inconvénients 1. La mise en cluster des données maximise les performances des applications gourmandes en E/S. Si toutes les données sont en mémoire, l'index de clustering n'a aucun avantage. 2. La vitesse d'insertion dépend fortement de l'ordre d'insertion. L'insertion dans l'ordre de la clé primaire est le chemin le plus rapide. Si les données sont trop volumineuses, cela entraînera un fractionnement de page. 3. Le coût de la mise à jour de la colonne d'index clusterisé est très élevé, car cela forcera chaque ligne mise à jour à se déplacer vers un nouvel emplacement.
4. Lorsqu'une table basée sur un index clusterisé insère une nouvelle ligne, ou lorsque la clé primaire est mise à jour et que la ligne doit être déplacée, elle peut être confrontée au problème de fractionnement de page
Les index clusterisés peuvent ralentir les analyses de table complètes, en particulier lorsque les lignes sont clairsemées ou que le stockage des données n'est pas contigu en raison de fractionnements de page
fusion de page mysq, fractionnement de page
À partir de MySQL 5.6, le paramètre innodb_file_per_table est défini sur 1 par défaut. Dans cette configuration, chacune de vos tables sera stockée dans un fichier séparé (s'il y a des partitions, il peut y avoir plusieurs fichiers). Il y a plusieurs segments dans un fichier, chaque segment est composé de plusieurs zones et chaque zone est composée de plusieurs pages.
Chaque page par défaut est de 16 Ko 10384 caractères,
chaque zone est par défaut de 1M, donc une zone est de 64 pages
Chaque page comporte un champ MERGE_THRESHOLD, qui correspond par défaut à 50 % de la taille de chaque page.
Lorsque les dernières données de la page en cours s'avèrent impossibles à stocker, un fractionnement de page peut se produire. Au contraire, si MERGE_THRESHOLD< 50%, il trouvera une page vers l'avant et fusionnera les pages.
Fusion de pages et fractionnement de pages, s'il faut ajouter des pages dans l'ordre
Par exemple, il y a déjà #11 et #12. Lorsque les données stockées dans #11 sont trop volumineuses, diviser un #13 entraînera un désordre dans l'ordre des pages entre #11 et #12. À ce moment, le tableau doit être réorganisé. D'autre part, rappelez-vous que lors de la fusion et du fractionnement, InnoDB ajoutera un verrou en écriture (x-latch) à l'arbre d'index. Cela peut être un danger caché dans un système avec des opérations lourdes
index non clusterisé
Les fichiers de données sont stockés séparément des fichiers d'index
refactorisation d'index
Lorsque la profondeur est >=4 ou DEL_LF_ROWS/LF_ROWS>0.2 ou que l'index est incliné à gauche et à droite, il doit être reconstruit
Supprimez l'index d'origine, puis créez l'index : créez l'index nom_index sur nom_table (colonne_index) ; cette méthode prend beaucoup de temps.
Reconstruisez l'index directement : alter index indexname restart online ; cette méthode est plus rapide et est recommandée.
reconstruction est un moyen efficace de reconstruire rapidement des index car c'est un moyen d'utiliser des entrées d'index existantes pour reconstruire un nouvel index. Alter index indexname rebuild peut créer un index, mais afin d'empêcher d'autres utilisateurs d'opérer sur cette table lors de la reconstruction de l'index, essayez d'utiliser le paramètre online pour minimiser les problèmes de verrouillage qui se produiront lors de la reconstruction de l'index. Étant donné que l'ancien et le nouvel index existent en même temps, l'utilisation de cette méthode de reconstruction nécessite de l'espace disque supplémentaire pour une utilisation temporaire. Une fois l'index créé, supprimez l'ancien index. En cas d'échec, l'index d'origine ne sera pas affecté. Cette approche peut être utilisée pour déplacer un index vers un nouveau tablespace.
échec d'indexation
règle optimale du préfixe gauche
Les calculs, les fonctions, les conversions de type (automatiques ou manuelles) entraînent l'invalidation de l'index
L'index de colonne sur le côté droit de la condition de plage n'est pas valide
Non égal (!= ou <>) invalide l'index
est nul peut utiliser l'index, n'est pas nul ne peut pas utiliser l'index
like commence par le joker % et l'index n'est pas valide
C'est une conception intéressante. Par exemple, si vous voulez utiliser comme, mais % ne peut être placé que plus tard. Ensuite, il y a une opération de changement d'espace pour le temps, en ajoutant une colonne d'ordre inverse (pouce 54321) en plus de la colonne courante (pouce 12345). Ensuite, vous pouvez aimer que le dernier % soit équivalent au même avant % de la colonne précédente.
Tant qu'il y a des colonnes non indexées avant et après OR, l'index sera invalidé ?
Le format d'encodage du champ associé à la requête de jointure à gauche ou à la requête de jointure à droite est différent
Mysql pense qu'il est plus rapide de ne pas utiliser l'index
Enfin, un mini-scénario de couverture d'indice de l'autotest
Lorsque le nom et l'âge de l'index combiné sont utilisés et que la requête SQL est select name where age, étant donné que les nœuds feuilles de l'index contiennent ces deux données, il n'est pas nécessaire d'accéder à la table de la base de données pour la requête. Est-ce l'utilisation de la couverture de l'indice. Mais type d'efficacité = indice.
Lorsque vous n'utilisez qu'un seul index d'âge, mais que le type de requête = ref
