MySQL (analyse InnoDB): --- Gestion d'index d'arborescence B + (gestion d'index, création d'index rapide, changement de schéma en ligne, DDL en ligne)

Aujourd'hui, c'est le jour du Nouvel An lunaire officiel, mon frère est ici pour souhaiter à tous les amis et grands frères un joyeux Nouvel An chinois et une réunion de famille!

Premièrement, la gestion des index

• Il existe deux façons de créer et de supprimer des index:
  • L'un est ALTER TABLE
  • L'autre est CREATE / DROP INDEX

Utiliser la grammaire

• Par exemple, il y a une table ci-dessous et un index de clé primaire est spécifié lors de la création de la table

create table t(
    a int not null,
    b varchar(8000),
    primary key(a)
)engine=innodb;

• Ajoutez maintenant un champ c, et sur l'index de champ c

 

alter table t add c int not null;
 
alter table t add key idx_c(c);

• Vous pouvez également indexer uniquement la partie de début d'une colonne, par exemple, indexer uniquement les 100 premiers champs du champ b

alter table t add key idx_b(b(100));

• Bien entendu , une indexation conjointe peut également être effectuée

alter table t add key idx_a_c(a,c);

 

 

Commande SHOW INDEX

• Cette commande peut être utilisée pour afficher les informations d'index. Vous pouvez voir qu'il y a 4 index sur la table t, à savoir:
  • Index de clé primaire
  • index secondaire sur la colonne c , l'index secondaire 100 octets avant la configuration de la colonne b , et (A, c) l'index secondaire combiné

 

La signification de chaque colonne de show index est la suivante:

• Table: le nom de la table où se trouve l'index
• Non_unique: index non unique, vous pouvez voir que la clé de parimaire est 0, car elle doit être unique
• Key_name: le nom de l'index, l'utilisateur peut exécuter DROP INDEX par ce nom
• Seq_in_index: La position de la colonne dans l'index, si vous regardez l'index joint idx_a_c, c'est plus intuitif
• Column_name: le nom de la colonne d'index
• Collation: De quelle manière la colonne est-elle stockée dans l'index. Peut être A ou NULL. L'index de l'arborescence B + est toujours A, c'est-à-dire trié. Si le moteur de stockage Heap est utilisé et qu'un index de hachage est établi, NULL sera affiché ici. Parce que Hash stocke les données d'index en fonction du compartiment Hash, au lieu d'indexer les données
• Cardinalité: valeur très critique, qui représente une estimation du nombre de valeurs uniques dans l'index. Le nombre de lignes dans la table Cardinality doit être aussi proche que possible de 1, s'il est très petit, l'utilisateur doit alors se demander si cet index peut être supprimé
• Sub_part: indique si une partie de la colonne est indexée. Si vous regardez l'index de idx_b, 100 est affiché ici, ce qui signifie que seuls les 100 premiers caractères de la colonne b sont indexés. Si la colonne entière est indexée, le champ est NULL
• Packed: Comment les mots-clés sont compressés. S'il n'est pas compressé, il est NULL
• Null: indique si la colonne indexée contient des valeurs NULL. Vous pouvez voir que idx_b est oui ici, car la colonne définie autorise les valeurs NULL
• Index_type: le type d'index. Le moteur de stockage InnoDB ne prend en charge que les index d'arborescence B +, donc tous les éléments affichés ici sont BTREE
• Commentaire: Commentaire

 

 

Valeur de cardinalité et commande ANALYZE TABLE

• La valeur Cardinality est très critique et l'optimiseur déterminera s'il faut utiliser cet index en fonction de cette valeur
• Mais cette valeur n'est pas mise à jour en temps réel, c'est-à-dire qu'elle n'est pas mise à jour à chaque fois que l'index est mis à jour, car le coût est trop élevé
• Cette valeur n'est pas précise, mais approximative. Si vous souhaitez mettre à jour les informations de cardinalité de l'index, vous pouvez utiliser la commande ANALYZE TABLE.
• Par exemple, nous insérons 4 enregistrements dans la table

insert into t select 1,repeat('a',7000),-1;
insert into t select 2,repeat('a',7000),-2;
insert into t select 3,repeat('a',7000),-3;
insert into t select 4,repeat('a',7000),-4;

• Avant l'insertion, dans l'image montrant SHOW INDEX ci-dessus, vous pouvez voir que la cardinalité est 0, mais après avoir inséré les données, la valeur devient 4

• Bien sûr, s'il n'y a pas de mise à jour, vous pouvez utiliser la commande ANALYSER pour mettre à jour

• Toutefois, les résultats obtenus à l'aide de cette commande sur chaque système peuvent être différents , car il existe encore des problèmes avec la commande ANALYSER TABLE, qui peuvent affecter le résultat final.
• Un autre problème est que la base de données MySQL compte Cardinality . Après une exécution pendant un certain temps, vous pouvez obtenir les résultats suivants:

• Ici, Cardinality devient NULL Dans certains cas, il peut arriver que l'index soit créé mais pas utilisé . Ou exécutez EXPLAIN sur deux instructions fondamentalement identiques, mais le résultat final est différent : l' une utilise un index et l'autre utilise une analyse complète de la table. La meilleure façon à ce stade est de faire une opération ANALYSE TABLE
• Par conséquent, je me suis configuré en période creuse pour effectuer des opérations ANALYZE TABLE sur plusieurs tables principales sous l'application, ce qui peut améliorer l'optimiseur et l'index.

 

 

2. Technologie de création d'index rapide

Avant MySQL 5.5

• Avant MySQL 5.5 (hors 5.5), un problème courant est que la base de données MySQL ajoute ou supprime de telles opérations DDL pour les index.
• Le processus de fonctionnement de la base de données MySQL est :
  • Créez d'abord une nouvelle table temporaire, la structure de la table est la structure nouvellement définie via la commande ALTER TABLE
  • Importez ensuite les données de la table d'origine dans la table temporaire
  • Puis supprimez la table d'origine
  • Enfin, renommez la table temporaire avec le nom de table d'origine
• Désavantages:
  • Si l'utilisateur ajoute et supprime un index sur une grande table, cela prendra beaucoup de temps
  • Plus important encore, si un grand nombre de transactions doivent accéder à la table en cours de modification, cela signifie que le service de base de données n'est pas disponible
• Le chemin de création de la table temporaire est défini par le paramètre tmpdir . L'utilisateur doit s'assurer que tmpdir dispose de suffisamment d'espace pour stocker la table temporaire, sinon cela entraînera l'échec de la création de l'index

• Technologie Fast Index Creation: Cette technologie est supportée depuis InnoDB 1.0.X, appelée "Fast Index Creation", ou FIC en abrégé
• Précautions:
  • Étant donné que FIC ajoute des verrous S à la table pendant le processus de création de l'index, la table ne peut être lue que pendant le processus de création . Si un grand nombre de transactions doivent écrire dans la table cible, le service de base de données est également indisponible.
  • De plus, FIC est uniquement limité aux index secondaires , la création et la suppression de clés primaires nécessitent également de reconstruire une table

Comment rapide Index Création fonctionne

• Créer un index : Pour la création d'index auxiliaires, InnoDB ajoutera un verrou S à la table où l' index est créé. Pendant le processus de création, il n'est pas nécessaire de reconstruire la table, donc la vitesse est beaucoup plus élevée qu'avant, et la disponibilité de la base de données a également été améliorée
• Supprimer l'index : supprime les opérations d'indexation auxiliaires encore plus simples, InnoDB met simplement à jour la vue interne , et l'espace est marqué comme index secondaire disponible , et supprime la base de données MySQL à l'intérieur de la vue de la table d'index peut être définie

 

3. Technologie de changement de schéma en ligne

• OSC (Online Schema Change) a d'abord été implémenté par Facebook comme moyen d'exécuter DDL en ligne, et a été largement utilisé dans la base de données MySQL de Facebook. Le soi-disant «en ligne» signifie que dans le processus de création de la transaction, il peut y avoir des transactions de lecture et d'écriture à opérer sur la table , ce qui améliore la concurrence de la base de données MySQL originale pendant les opérations DDL

Principe de réalisation

• Facebook utilise des scripts PHP pour implémenter OSC, pas en modifiant le code source du moteur de stockage InnoDB. OSC a été développé à l'origine par Vamsi Ponnekanti, employé de Facebook. De plus, OSC s'appuie sur l'outil précédent The openarkkit toolkit oak-online-table de la communauté open source
• Les étapes de mise en œuvre de l'OSC sont les suivantes:

 

• Les chiffres ci-dessus ne présentent que brièvement le processus d'implémentation d'OSC. Le script proprement dit est très compliqué. Le code de base PHP d'OSC compte à lui seul plus de 2 200 lignes. De nombreux points de connaissance de MySQL InnoDB sont utilisés. Il est recommandé aux développeurs de bases de données et de DBA essayez de lire ceci. Aide à mieux comprendre l'utilisation du moteur de stockage INnoDB
• Étant donné que OSC n'est qu'un script PHP, il présente certaines limitations. Par exemple, la table à modifier doit avoir une clé primaire et la table elle-même ne peut pas avoir de clés étrangères et de déclencheurs. De plus, pendant le processus OSC, SET sql_bin_log = 0 est autorisé, donc l'opération ne synchronisera pas le serveur esclave, ce qui peut entraîner l'incohérence du maître et de l'esclave

Quatrièmement, la technologie DDL en ligne

 

• Bien que FIC permette à InnoDB d'éviter de créer des tables temporaires, améliorant ainsi l'efficacité de la création d'index. Mais comme mentionné dans la section précédente, les opérations DML sur la table seront bloquées lors de la création de l'index. Bien que OSC résout certains des problèmes ci-dessus, il a encore de grandes limitations
• La version MySQL 5.6 a commencé à prendre en charge les opérations Online DDL (Online Data Definition) , ce qui permet la création d'index auxiliaire, mais permet également d'autres opérations DML telles que INSERT, UPDATE, DELETE, ce qui améliore considérablement la disponibilité de la base de données MySQL dans l'environnement de production
• En outre , non seulement l'index auxiliaire, mais les types suivants d'opérations DDL peuvent tous être exécutés "en ligne":
  • Création et suppression d'index auxiliaires
  • Changer la valeur de la croissance personnelle
  • Ajouter ou supprimer des contraintes de clé étrangère
  • Renommer la colonne

 

Commande ALTER TABLE

• Grâce à la nouvelle syntaxe ALTER TABLE, les utilisateurs peuvent choisir comment créer un index:

Paramètres ALGORITHM

• Ce paramètre spécifie l'algorithme de création ou de suppression d'index
• Les valeurs facultatives sont les suivantes:
  • COPY : Conformément au mode de fonctionnement avant MySQL 5.1, c'est-à-dire la façon de créer une table temporaire
  • INPLACE : indique que l'opération de création ou de suppression d'index n'a pas besoin de créer une table temporaire
  • DEFAULT : indique s'il faut utiliser l'algorithme INPLACE ou COPY selon le paramètre old_alter_table. (Ce paramètre est OFF par défaut, ce qui signifie que la méthode INPLACE est utilisée)

Paramètre LOCK

• Ce paramètre est le cas de l'ajout d'un verrou à la table lors de la création ou de la suppression de l'index
• Les valeurs facultatives sont les suivantes:
  • AUCUN : Lors de l' exécution d'une opération de création ou de suppression d'index, aucun verrou n'est ajouté à la table cible, c'est-à-dire que la transaction peut toujours effectuer des opérations de lecture et d'écriture sans être bloquée. Par conséquent, ce mode peut atteindre une concurrence maximale
  • SHARE : Ceci est similaire au FIC précédent. Lorsqu'un index est créé ou supprimé, un verrou S est ajouté à la table cible. Pour les transactions de lecture simultanées, elle peut toujours être exécutée, mais lorsqu'une transaction d'écriture est rencontrée, une opération d'attente se produit. Si le moteur de stockage ne prend pas en charge le mode SHARE, un message d'erreur sera renvoyé
  • EXCLUSIF : dans ce mode, lorsqu'un index est créé ou supprimé, un verrou X est ajouté à la table cible. Les transactions de lecture et d'écriture ne peuvent pas être effectuées, donc tous les threads sont bloqués. Ceci est similaire à l'état obtenu en s'exécutant en mode COPY, mais il n'est pas nécessaire de créer une table temporaire comme en mode COPY
  • DEFAULT : Ce mode déterminera d'abord si l'opération en cours peut utiliser le mode NONE, sinon, il déterminera si le mode SHARE peut être utilisé, et enfin s'il peut utiliser le mode EXCLUSIVE. En d'autres termes, DEFAULT jugera le mode d'exécution de DDL en jugeant la concurrence maximale de la transaction

Fonctionnement du DDL en ligne

• Lors de l'exécution des opérations de création ou de suppression, les journaux des opérations DML tels que INSERT, UPDATE et DELETE sont écrits dans un cache . Une fois l'index créé, la restauration est appliquée à la table pour assurer la cohérence des données

 

Cache du journal (paramètre innodb_online_alter_log_max_size)

• Dans le principe de fonctionnement, nous avons introduit que le journal des opérations DML sera écrit dans un cache. La taille du cache est contrôlée par le paramètre innodb_online_alter_log_max_size, et la valeur par défaut est de 128 Mo
• Si la table mise à jour par l'utilisateur est relativement volumineuse et accompagnée d'un grand nombre de transactions d'écriture pendant le processus Transcend, l' erreur suivante peut se produire lorsque l'espace du cache ne peut pas stocker le journal: 

 

• Si le cache ne suffit pas, vous pouvez ajuster ce paramètre pour augmenter l'espace du cache
• Si le mode d'ALTER TABLE est SHARE, il n'y aura aucune transaction d'écriture pendant l'exécution, il n'est donc pas nécessaire d'enregistrer le journal DML

• Une attention particulière est nécessaire : étant donné que le DDL en ligne atteint la cohérence finale de la base de données via le journal de rétablissement après la création de l'index, cela signifie que pendant le processus de création de l'index, l'optimiseur SQL ne sélectionnera pas l'index en cours de création.