Optimisation de l'index MySQL en un coup d'œil (cas réel)

Contexte

(Base de données utilisée: MYSQL version 5.7, moteur InnoDB)
Depuis que Skywalking a été ajouté au service, la plupart des interfaces lentes ont été exposées. Il y a donc l'optimisation de cette interface lente. Le processus d'optimisation approximatif.

• Avant l'optimisation:
  

• Optimisé:
  

Les étapes d'optimisation

1. Enquête

1. Grâce au skywalking, vous pouvez clairement voir à quelle étape l'interface lente est la plus lente. Grâce à la situation d'appel, vous pouvez clairement voir la situation d'appel de liaison comme indiqué ci-dessous:
   

Si votre service n'est pas connecté au service de surveillance dans cette situation, nous pouvons utiliser Arthas open source d'Alibaba pour suivre le lien (utilisez trace pour afficher la méthode chronophage de chaque étape) arthas document officiel

2. Enregistrez la situation actuelle

2. Après l'enquête, nous pouvons localiser avec précision le SQL est très lent. À ce stade, nous devons analyser ce SQL attentivement, d'abord sortir le SQL métier (obtenu via le journal de la console), et afficher le plan d'exécution SQL via Expliquer. Très important. Vérifiez s'il existe un index de marche, vérifiez le nombre de lignes de pré-scan, la stratégie d'exécution, etc. Les mots ici reposent principalement sur les informations qui nous sont fournies par chaque champ de l'explication. (Running est la bibliothèque de production). Enregistrez les principales informations obtenues.

Index utilisé	Nombre de lignes de pré-scan	S'il faut retourner à la table	S'il faut trier	temps d'exécution	en conclusion

3. Déterminer le plan d'optimisation spécifique en fonction de la situation et analyser les raisons

1. Mauvais index

1. - 这种情况我们呢可以查看他的索引基数通过 show index from table_name.大概看一下cardinality基数字段，大概评估一下。然后使用命令 analyze table tb_name重新计算一下。
    - 因为对与mysql选择索引其中索引基数是重要条件之一
    - 索引基数是通过抽样计算计算出来的，所以不一定是准确的，所以通过analyze table进行重新采样计算后就可以了。
2. - 如果说通过索引基数还没有OK的话，那就有可能是在这条语句中与可能有排序或者有创建临时表的情况，使用这个你认为扫描行数少的有可能产生。所以你可以考虑优化索引了，创建一个符合索引且不需要回表的

2. Discrimination à faible indice

• Ce qu'il faut noter ici, c'est d'utiliser le moins possible certaines valeurs d'état pour créer des index. Pourquoi? Après avoir construit un arbre B +, la plupart de vos valeurs sont les mêmes et la complexité temporelle de la recherche est probablement à peu près la même que celle d'une liste chaînée ordinaire. Ici, nous pouvons vraiment le tuer de manière décisive.
• L'autre est que la première moitié est fondamentalement la même, et la dernière partie présente quelques différences. Dans ce cas, nous pouvons utiliser le stockage flashback, puis l'utiliser pour créer un index, et n'utiliser que la partie avec un degré de distinction élevé pour le stockage. En d'autres termes, stockez un autre champ comme valeur de hachage et utilisez la valeur de hachage comme index. Utilisez le hachage calculé directement pour correspondre lors de la recherche

3. Utilisez l'index pour revenir à la table, il y a un tri

• Revenir à la table signifie que les données que nous trouvons via un index ne peuvent pas parcourir lentement les champs dont nous avons besoin, et il doit parcourir l'ID collecté via l'index de clé primaire pour obtenir les informations de champ correspondantes. Ensuite, notre solution est d'utiliser un index de recouvrement. Créez un index qui répond aux champs obligatoires. Ce qu'il faut noter ici, c'est qu'il a déjà été évalué. Vous ne pouvez pas créer un index conjoint avec une seule requête. L'autre est de se conformer au principe de correspondance le plus à gauche, et le degré de discrimination doit être important.
• Il y a tri, c'est-à-dire que lorsqu'il y a tri de fichiers lors de l'explication, cette opération effectuera des opérations d'E / S et triera. Nous créons donc un index conjoint avec ce champ. Par exemple, nous interrogeons l'index conjoint de la commande correspondant à l'ID en fonction de l'ID utilisateur et triés par create_time. En fait, il existe une autre situation qui est que si la commande utilisateur comporte plusieurs millions de commandes, les performances de la requête chuteront d'un coup, alors nous pouvons utiliser Les exigences métier sont optimisées, c'est-à-dire qu'un intervalle de temps est limité dans l'instruction where.

（id，create_time）

4. Mon plan final pour SQL est d'en changer deux et d'en ajouter un

1. Changer l'index avec une faible discrimination et ne pas suivre le principe de correspondance le plus à gauche
2. Créer un index conjoint pour éliminer le tri des fichiers
3. Optimisation de la logique métier, optimisation simple de SQL complexe, suppression de la logique imbriquée
4. Combinez la logique métier avec l'intervalle de temps (un mois avant l'heure actuelle).

3. Vérification stricte et efficace

Ceci est l'étape la plus importante

Mon plan de vérification:

3. Grâce à ma propre compréhension de l'entreprise, j'évalue l'énoncé d'index modifié qui sera utilisé et je le teste. Ici, vous pouvez le comparer avec la bibliothèque de production
4. L'utilisation de l'index d'origine a été enregistrée, puis le SQL d'origine est exécuté dans la base de données de l'environnement SIT, et (notre bibliothèque SIT a synchronisé les données de PROD, mais il manque encore des données)
5. Lorsque vous exécutez SQL, essayez de choisir les conditions de filtrage autant que possible: utilisez l'index, et les données ne seront pas filtrées, pour éviter que la situation accidentelle des données soit classée au premier plan et ne frappe très tôt.
6. Ensuite, les étudiants du test effectueront un test de pression avec notre interface optimisée.
7. C'est un test de régression complet. Cliquez sur chaque page de requête
8. Heureusement, les performances ont été améliorées de 1000, passant de dizaines de secondes à moins de 1 ms, et cela n'a aucun effet sur les autres interfaces métier.

4. L'index est en ligne

1. La modification de l'index n'est rien de plus que la suppression de l'index et la création de l'index. Ici, vous devez faire attention à la table de verrouillage qui peut être causée pendant le processus de modification. Ici, nous pouvons jeter un œil à la syntaxe de Online DDL (https://dev.mysql.com/doc/refman/5.7/en/ innodb-online-ddl-operations.html)
2. Les affaires de l'entreprise le permettent, mais j'ai arrêté le service au milieu de la nuit. Mais il a été exécuté pendant 1 heure (9 millions de données)

Hallucination

Dans le travail réel, de nombreux étudiants pensent que l'ajout d'un index affectera l'efficacité de la mise à jour. Mais cet impact est très faible pour l'impact des requêtes lentes.

Pour résumer

• Un processus que je me suis optimisé
• L'utilisation d'expliquer (https://segmentfault.com/a/1190000008131735)
• Plusieurs cas de problèmes d'index
• Des tests stricts sont très importants (mon test pense personnellement qu'il est moyen)

Les données

• Index optimisé de Meituan: https://tech.meituan.com/2014/06/30/mysql-index.html
• Utilisation d'expalin: https://dev.mysql.com/doc/refman/5.7/en/using-explain.html
• Syntaxe DDL en ligne: https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html
• document officiel arthas: https://alibaba.github.io/arthas/trace.html)