Analyse de cas de tri lent d'index clusterisé Mysql

Pourquoi le moteur mysiam devrait-il être utilisé lors de l'exécution de nombreuses sélections ? Surtout quand il y a un index

Cet article s'appuie sur une application pratique et l'analyse.

1. Préface :

J'ai vu un phénomène intéressant en ligne. Une table avec un volume de données de 1 W exécute différentes conditions de commande et un temps de requête très important. un vrai problème dans les applications pratiques ? ? Pourquoi?

2. Analyse

a). Description de la situation :

1. ); L'utilisation du premier pour la requête orderby est lente, tandis que l'utilisation du second pour la requête orderby sera très rapide

2 La quantité de données dans chaque ligne est assez importante

3. est l'index principal, et les champs de la requête de sélection le sont également. S'il n'y a qu'un identifiant, alors l'index le couvre. Vous n'avez pas besoin d'accéder au disque physique pour récupérer les données. Vous pouvez obtenir les données souhaitées. sur l'index, mais la requête qui devrait être plus rapide est plus lente. Couverture de l'index MySQL

b). Analyse :

ne doit pas utiliser le moteur mysiam. Si c'est le cas, la vitesse de requête utilisant ces deux index est presque la même. , car Ce qui est stocké dans l'index est l'adresse d'une ligne physique et la quantité réelle de données occupées n'est pas importante. Mais c'est différent s'il s'agit d'innodb. Toutes les données de la ligne sont stockées sous son index principal.

c). Conclusion :

1. Raison principale : Le moteur innodb utilisé

est un index clusterisé, et l'index d'ID de clé primaire est également lié à la ligne. Autres données, donc lors du tri selon l'ID, vous devez traverser de nombreux petits blocs pour interroger et parcourir chaque ID (il n'y a pas tellement de données sous mysiam, il sera plus rapide de traverser le même bloc de données et de parcourir plus de lignes)

2. Raison : La quantité de données dans plusieurs domaines est relativement importante, c'est-à-dire que de nombreuses personnes amènent leur famille avec elles, et la quantité de données est relativement importante. La quantité de données dans chaque ligne est importante et prend de nombreux blocs lors du stockage sur disque

3 Ce problème n'existait pas dans le moteur mysiam à cette époque

d). conclusion :

Lorsque de nombreuses sélections sont exécutées, le moteur mysiam doit être utilisé

Lorsque de nombreuses insertions et mises à jour sont exécutées, le moteur innodb doit être utilisé

<.>Pour plus de conclusions, veuillez consulter : Résumé de l'index Mysql

3. Test de simulation

Restaurez les conditions mentionnées ci-dessus, créez deux tables et contrôlez les variables À l'exception des différents moteurs, le. les autres conditions sont les mêmes, index primaire d'ID de clé primaire, index conjoint (id, ver).

1. Créez une nouvelle table t7, moteur mysiam

2. Insérez aléatoirement 10 000 données

3. Exécutez l'instruction de requête et vérifiez l'heure

Évidemment, le le décalage horaire n'est pas trop grand, ils sont tous de la même ampleur.

4. Créez une nouvelle table t8, moteur innodb

5. Insérez au hasard 10 000 éléments de données

Petite histoire, lors de l'exécution de l'instruction selon le script ci-dessus, le temps d'attente est très long. Pourquoi ? Puisqu'il s'agit d'un index clusterisé avec un ID d'index de clé primaire, lorsque l'index de clé primaire est créé, un grand nombre de blocs de données de ligne sont déplacés et il reste du temps pour le fractionnement et le déplacement.

L'opération consiste d'abord à supprimer l'ID d'index de clé primaire, à insérer les données puis à ajouter la clé primaire (id), puis à créer la structure d'index de clé primaire

6. Exécutez l'instruction de requête, vérifiez l'heure

Évidemment, le décalage horaire est très différent.

Raison : les deux instructions utilisent un index clusterisé, mais la clé primaire s'étend sur trop de blocs, tandis que l'index conjoint est un index secondaire sans données en dessous, avec moins de blocs et un parcours rapide.

7. Analyse globale, seule la table t8 (innodb) met beaucoup de temps à trier selon l'index de clé primaire, le reste va bien

Conclusion du tri temporel : innodb. Index primaire> Index secondaire>

L'efficacité est près de 27 fois pire.

1. La raison principale est de faire un tri en fonction de la clé primaire. La requête s'étendra sur plusieurs blocs sur la page, ce qui augmente le temps

2. champs de caractères longs, le bloc de données ne sera pas volumineux, cela ne causera pas une si grande différence,

Par exemple, si vous supprimez les champs str1, str2, str3 dans la table, l'heure de la requête sera considérablement réduit, et la différence ne sera pas évidente

Ce qui précède est le contenu de l'analyse de cas du tri lent des index clusterisés Mysql. Pour plus de contenu connexe, veuillez faire attention. sur le site Web PHP chinois (www.php.cn) !