Partagez certains des problèmes que j'ai rencontrés au cours de trois jours de réglage des performances

Ces derniers jours, j'ai examiné une procédure stockée optimisée en termes de performances. La durée d'exécution de cette procédure stockée dans l'environnement de production du client (la base de données est MySQL 5.1) est supérieure à 30 à 40 minutes. la demande est d'améliorer

Mise en œuvre de cette procédure stockée :

1. Requête de deux tables (en raison des besoins de l'entreprise, implique également des sous-requêtes de la table), insérées respectivement dans les tables temporaires ; des deux tables sont 310W+, 120W

2. Certains traitements doivent être effectués au milieu, et le groupe de données de la table temporaire est inséré dans une autre table temporaire

3. Enfin, le groupe de données de la table temporaire est inséré. Je suis arrivé à une table formelle et j'ai inséré 140W+ de données

Ensuite, je suis allé de plus en plus loin sur la voie de l'optimisation des performances ces derniers jours, en essayant toutes sortes de méthodes et expérimenter toutes sortes d'épreuves.

Images de l'application

Diverses tentatives :

1. J'ai l'impression que la logique de cette implémentation est un peu complexe , puis j'ai simplifié la mise en œuvre selon mes idées. Cependant les performances ne sont pas améliorées. Parce que mon implémentation met la grande quantité de données au premier plan et que les opérations ultérieures doivent fonctionner sur cette grande quantité de données, comme le regroupement par. Ainsi, bien que mon implémentation soit logiquement simplifiée, les performances ne sont pas améliorées.

2. Sur la base de différents identifiants logiques, deux ensembles de tables temporaires sont créés, de sorte que la quantité de données dans une table ne soit pas si importante, dans l'espoir de réduire une certaine pression sur les opérations ultérieures. Cela s'est quand même soldé par un échec. La raison en est qu'en raison de la définition d'identifiants logiques, tout est basé sur un ensemble de logique. Le deuxième ensemble de logique n'est qu'une formalité et ne vérifiera pas réellement la table avec des millions de données, donc la pression est toujours sur la table. avec plus de 3 millions.

3. Utilisez des déclarations préparées. En fait, je ne connais pas grand-chose au mécanisme des instructions de prétraitement. Je viens d'entendre que le prétraitement est plus efficace. Les performances ne sont toujours pas améliorées, probablement parce qu’il n’existe pas beaucoup de requêtes ou d’insertions similaires. Hmm, je ne comprends pas très bien le mécanisme de prétraitement.

4. Supprimez la sous-requête et utilisez une table temporaire pour enregistrer cette partie des données. De cette façon, la table contenant plus de 3 millions de données doit encore être vérifiée deux fois, et il n'y a aucune amélioration des performances.

5. Changez le moteur de la table temporaire de myisam en mémoire. Les variables globales max_heap_table_size et tmp_table_size de la base de données sont également définies sur 1000M, ce qui est le même que l'environnement de production. Le résultat indique toujours

The table 'tmp_item_bu_parter_price' is full

, donc la quantité de données est trop importante, provoquant un éclatement de la mémoire ?

Sixièmement, j'ai également suivi différentes branches de logique, mais j'ai constaté qu'elles suivaient toutes la même logique. C'est un peu un inconvénient. J'y ai réfléchi longtemps auparavant et je n'ai pas d'abord découvert les paramètres du client.

7. Multi-thread. Étant donné que la syntaxe insert into ...select... est utilisée dans la procédure stockée et que la condition Where n'est pas indexée, un verrouillage complet de la table est provoqué. Le résultat du test multithread est sans aucun doute la table de verrouillage, et certaines exécutions de données échouent.

8. Logiquement, il n'est pas inséré dans son intégralité, mais par incréments, mais les données existantes doivent encore être mises à jour. Les performances devraient donc être à peu près les mêmes.

Les performances sont principalement consommées par l'insertion de millions de données. Maintenant, je suis complètement perdu et je ne sais pas comment y faire face.

[Recommandations associées]

1.

Tutoriel vidéo en ligne MySQL gratuit

2.

Dernier tutoriel manuel MySQL.

3.

Choses sur la conception de bases de données

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!