Introduction détaillée du code graphique des techniques d'optimisation MySql SQL

Cet article présente principalement le partage des compétences d'optimisation MySql SQL. Il est très bien et a une valeur de référence. Les amis dans le besoin peuvent s'y référer

Un jour, j'ai trouvé un SQL avec jointure interne, bien que l'exécution. la vitesse n'est pas très lente (0,1-0,2), mais la vitesse idéale n'est pas atteinte. Les deux tables sont liées, les champs associés sont des clés primaires et les champs interrogés sont des index uniques.

sql est le suivant :

SELECT
p_item_token.*,
p_item.product_type
FROM
p_item_token
INNER JOIN p_item ON p_item.itemid = p_item_token.itemid
WHERE
p_item_token.token ='db87a780427d4d02ba2bd49fac8xxx';

Dans la table p_item_token itemid est la clé primaire et token est l'index unique. itemid dans p_item est la clé primaire

Selon la vitesse idéale, elle devrait être d'environ 0,03 s. Mais la valeur réelle est d'environ 0,2, ce qui est beaucoup plus lent.

EXPLIQUEZ directement pour voir le plan

EXPLAIN
SELECT
  p_item_token.*,
  p_item.product_type
FROM
  p_item_token
INNER JOIN p_item ON p_item.itemid = p_item_token.itemid
WHERE
  p_item_token.token = 'db87a780427d4d02ba2bd49fac8xxx';

Résultat :

Faites attention Grande boîte rouge ci-dessus. Il y a 2w éléments de données dans la table p_item, il s'agit donc d'une analyse complète de la table.

Ce n’est pas normal.

Ajoutez des avertissements d'affichage et jetez un œil. Remarque : Dans certains cas, AFFICHER LES AVERTISSEMENTS n'aura aucun résultat. Je ne connais pas encore la raison. Il est recommandé d'exécuter avec une base de données de test locale.

EXPLAIN
SELECT
  p_item_token.*,
  p_item.product_type
FROM
  p_item_token
INNER JOIN p_item ON p_item.itemid = p_item_token.itemid
WHERE
  p_item_token.token = 'db87a780427d4d02ba2bd49fac8xxx';
SHOW WARNINGS;

Le résultat 2 montre code=1003. Il y a une instruction SQL derrière. Cette instruction est la dernière instruction exécutée par MySQL après avoir réécrit l'instruction SQL que nous avons entrée selon les règles.

/* select#1 */
SELECT
  '0000eb612d78407a91a9b3854ffffffff' AS `itemid`,    /*注:直接按主键把值查出来了*/
  'db87a780427d4d02ba2bd49fac8cf98b' AS `token`,    
  '2016-12-16 10:46:53' AS `create_time`,        
  '' AS `ftoken`,                    
  `p_db`.`p_item`.`product_type` AS `product_type`  
FROM
  `p_db`.`p_item_token`
JOIN `p_db`.`p_item`
WHERE
  (
    (
      CONVERT (
        `p_db`.`p_item`.`itemid` USING utf8mb4
      ) = '0000eb612d78407a91a9b3854fffffff'
    )
  )

Étrange. Pourquoi y a-t-il CONVERT dans Où ? Nous savons que s’il y a une fonction sur le côté gauche de l’équation dans la condition où, c’est-à-dire le champ à interroger, cela entraînera une lenteur. (Ma compréhension : c'est lent car l'index n'est plus utilisé. La valeur de l'index est la valeur d'origine, mais la valeur traitée est utilisée dans cette condition.)

Faites attention à cette fonction, signifie changer itemid L'encodage de cette colonne est converti en utf8mb4 En d'autres termes, l'encodage de cette colonne n'est pas utf8mb4

Ouvrez le tableau et modifiez l'encodage de la colonne itemid dans les deux ! tables en utf8. Exécutez à nouveau l'explication.

À en juger par les résultats de l'interprétation, il n'y a pas de problème.

Regardez les déclarations dans le résultat 2 :

/* select#1 */
SELECT
  '0000eb612d78407a91a9b3854fffffff' AS `itemid`,
  'db87a780427d4d02ba2bd49fac8cf98b' AS `token`,
  '2016-12-16 10:46:53' AS `create_time`,
  '' AS `ftoken`,
  'cxx' AS `product_type`
FROM
  `toy_item_plat`.`p_item_token`
JOIN `toy_item_plat`.`p_item`
WHERE
  1

Cette sélection est entièrement constante. Est-ce que ça peut être plus rapide ?

Le résultat de l'exécution est de 0,036 s. Conforme aux attentes

Résumé de l'expérience :

expliquer Vous pouvez vérifier si le plan d'exécution est conforme aux attentes. S'il y a de grandes lignes, cela signifie qu'une analyse complète de la table a eu lieu, ce qui est le cas. sera un goulot d'étranglement des performances à l'avenir

afficher les résultats d'avertissement, vous pouvez voir l'instruction traitée par l'optimiseur. S’il y a une divergence avec la déclaration originale, une comparaison et une étude minutieuses peuvent révéler le problème réel.

Ce qui précède est l'introduction détaillée du code graphique des techniques d'optimisation MySql SQL. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !