Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. MySQL
Code

Écrire des requêtes MySQL ultra-rapides

by
Difficulty:IntermediateLength:LongLanguages:

French (Français) translation by Ahmad Fauzan (you can also view the original English article)

Les différences entre SQL bien écrit et non sont vastes et, en production sur un site à forte demande, elles ont de graves répercussions sur les performances et la fiabilité du service. Dans ce guide, nous expliquerons comment rédiger des requêtes rapides et quels facteurs contribuent à les ralentir.

Pourquoi MySQL?

On parle beaucoup aujourd'hui du Big Data et des nouvelles technologies. Les solutions NoSQL et en nuage sont excellentes, mais de nombreux logiciels Web populaires (tels que WordPress, phpBB, Drupal, le logiciel VBulletin Forum, etc.) fonctionnent toujours sur MySQL. Migration vers ces nouvelles solutions peut ne pas être aussi simple que d’optimiser la configuration que vous avez déjà en production. De plus, les performances de MySQL sont très bonnes, en particulier pour la version Percona.

Ne commettez pas l’erreur commune de disposer de plus en plus de puissance de calcul pour traiter le problème des requêtes lentes et des charges de serveur élevées, plutôt que de traiter réellement les problèmes sous-jacents. Ajouter de la puissance CPU, des SSD ou de la RAM est une forme d’optimisation, mais ce n’est pas ce dont je vais parler ici. En outre, sans site optimisé, les problèmes se multiplient de manière exponentielle à mesure que vous progressez avec les gains matériels.  Ce n’est donc pas une solution solide à long terme.

Être bon en SQL est toujours un outil essentiel pour un développeur Web, et comme une solution est souvent aussi simple que d’ajouter un index ou de modifier légèrement l’utilisation de la table, il est utile de savoir comment utiliser correctement son SGBDR. Dans ce cas, nous nous concentrons sur une base de données open source populaire souvent utilisée avec PHP, à savoir MySQL.

Pour qui ce Guide ?

Développeurs Web, architectes de bases de données / administrateurs de base de données et administrateurs système familiarisés avec MySQL. Si vous n'êtes pas familier avec MySQL en tant que débutant, alors ce guide n'aura probablement aucun sens, mais je vais essayer de le garder aussi informatif que possible pour les nouveaux arrivants à MySQL.

Sauvegarder la première

Je recommande d'essayer les étapes fournies sur votre propre base de données MySQL (sauvegarder tout d'abord bien sûr!). Si vous ne disposez d'aucune base de données sur laquelle travailler, des exemples de création de schémas de base de données sont fournis, le cas échéant.

Sauvegarder MySQL est facile avec l'utilitaire de ligne de commande mysqldump:

 Vous pouvez en apprendre plus sur mysqldump.

Qu'est-ce qui rend une requête lente?

En résumé et sans ordre d'importance, les éléments suivants jouent tous un rôle important dans les performances des requêtes et des serveurs:

  • index de table
  • Clause Where (et utilisation des fonctions internes de MySQL telles que IF et DATE par exemple)
  • tri avec Order By
  • fréquence des demandes simultanées
  • type de moteur de stockage (InnoDB, MyISAM, Memory, Blackhole)
  • ne pas utiliser Percona edition
  • les variables de configuration de serveur (tuning my.cnf / my.ini)
  • Jeux de résultats volumineux (> 1 000 lignes)
  • connexions non persistantes
  • sharding / cluster configuration
  • conception de table médiocre

Nous aborderons tous ces domaines dans ce guide. De plus, si vous ne l'utilisez pas déjà, installez Percona, un outil de remplacement immédiat pour MySQL, qui apportera une amélioration considérable des performances. Pour afficher un point de repère de Percona contre MySQL, regardez cette comparaison.

Quels sont les indices ?

MySQL utilise les index pour rechercher rapidement des lignes avec des valeurs de colonne spécifiques, par exemple dans un WHERE. Sans index, MySQL doit commencer par la première ligne, puis parcourir l'intégralité de la table pour rechercher les lignes appropriées. Plus la table est grande, plus cela coûte cher.

Si la table a un index pour les colonnes en question, MySQL peut rapidement déterminer la position à rechercher au milieu du fichier de données sans avoir à regarder toutes les données. C'est beaucoup plus rapide que de lire chaque ligne séquentiellement.

Connexions non persistantes ?

Lorsque votre langage de script se connecte à la base de données, si vous avez configuré des connexions persistantes, il pourra réutiliser une connexion existante sans en créer une nouvelle. Ceci est optimal pour une utilisation en production et doit être activé.

Les utilisateurs de PHP peuvent en savoir plus dans le manuel PHP.

Réduire la fréquence des demandes simultanées

Le moyen le plus rapide et le plus efficace que j'ai trouvé pour résoudre ce problème consiste à utiliser un magasin de paires clé-valeur tel que Memcached ou Redis.

Avec Memcache, vous pouvez simplement mettre en cache le contenu de votre requête avec les éléments suivants, par exemple:

À présent, l'exemple de requête LEFT JOIN ne sera exécuté qu'une fois toutes les 86 400 secondes (24 heures), ce qui allégera la charge de travail du serveur MySQL et réduira le nombre de connexions simultanées.

Remarque: Ajoutez p: à l'argument de votre hôte dans MySQLi pour les connexions persistantes.

Eclatement / Clustering

Lorsque vos données deviennent importantes ou que la demande pour votre service augmente, la panique peut s'installer. Une solution rapide pour vous assurer que votre service reste en ligne peut être précise. Mais je ne le recommande pas, car le sharding semble rendre les structures de données excessivement compliquées. Et comme expliqué très éloquemment dans cet article du blog Percona, ne partagez pas.

Pauvre Table Design

La création de schémas de base de données n’est pas une tâche ardue lorsque vous acceptez certaines règles d’or, telles que l’utilisation des limitations et la prise de conscience de ce qui sera efficace. Stocker des images dans la base de données sous forme de types de données blob, par exemple, est fortement déconseillé; stocker un nom de fichier dans une colonne de type de données varchar est de loin supérieur.

Il est primordial de créer votre application en veillant à ce que la conception corresponde à l'utilisation requise. Gardez les données spécifiques séparées (par exemple, les catégories et les publications) et assurez-vous que les relations plusieurs-à-un ou un-à-plusieurs peuvent être facilement liées à des identifiants. L’utilisation de la fonctionnalité FOREIGN KEY de MySQL est idéale pour la contingence de données en cascade entre les tables.

Lors de la construction de votre table, essayez de vous rappeler les points suivants:

  • Utilisez le minimum dont vous avez besoin pour faire le travail; être clairsemé et au point.
  • Ne vous attendez pas à ce que MySQL fasse la logique de votre entreprise ou soit programmatique - cela devrait être fait avant l’insertion par votre langage de script. Par exemple, si vous avez besoin de randomiser une liste, effectuez la randomisation d'un tableau en PHP, pas dans ORDER BY dans MySQL.
  • Utilisez un type d'index UNIQUE pour des ensembles de données uniques et utilisez ON DUPLICATE KEY UPDATE pour conserver un horodatage datetime ou unix mis à jour, par exemple pour le dernier contrôle de la ligne.
  • Utilisez un type de données INT pour les nombres entiers. Si vous ne spécifiez pas la longueur, MySQL calculera ce qui est demandé.

Les bases de l'optimisation

Pour optimiser efficacement, nous devons examiner trois ensembles de données fondamentaux concernant votre application:

  1. Analyse (enregistrement lent des requêtes, audit, analyse des requêtes et des tables)
  2. Exigences de performances (combien d'utilisateurs, quelle est la demande)
  3. Contraintes de technologie (vitesse matérielle, demander trop de MySQL)

L'analyse peut être effectuée de plusieurs manières. Premièrement, nous prendrons la voie la plus directe pour examiner sous le capot des requêtes MySQL. Le premier outil dans votre boîte à outils de l'optimisation est EXPLAIN. En utilisant ceci dans votre requête avant le SELECT, vous obtiendrez le résultat suivant:

Les colonnes répertoriées contiennent chacune des informations utiles sur la requête en cours d'exécution. Les colonnes sur lesquelles vous devez porter une attention particulière sont possible_keys et Extra.

possible_keys affichera les index que le moteur MySQL peut utiliser pour la requête. Parfois, vous devez forcer un index pour vous assurer que la requête est exécutée le plus rapidement possible.

La colonne Extra indique si un WHERE ou ORDER BY conditionnel a été utilisé. Le plus important à noter est si Utilisation de Filesort apparaît. Prenons l'exemple suivant:

Ce type de requête peut arriver sur le disque en raison du conditionnel where, ce qui se produit si nous examinons le fichier EXPLAIN:

Donc, cette requête a la possibilité d’utiliser deux index et elle frappe actuellement le disque en raison de l’utilisation de fichiers dans Extra.

Que fait à l’aide de Filesort est défini ici à partir du manuel MySQL :

"MySQL doit effectuer une passe supplémentaire pour savoir comment récupérer les lignes dans un ordre trié. Le tri s'effectue en parcourant toutes les lignes en fonction du type de jointure et en stockant la clé de tri et le pointeur sur la ligne pour toutes les lignes correspondant à la clause WHERE. Les clés sont ensuite triées et les lignes sont extraites dans un ordre trié."

Cette passe supplémentaire ralentira votre application et doit être évitée à tout prix. L'utilisation temporaire est un autre résultat essentiel à éviter, ce qui signifie que MySQL devait créer une table temporaire pour la requête. Évidemment, ceci est une utilisation hideuse de MySQL et doit être évité à tout prix, sauf si vous ne pouvez pas optimiser davantage en raison des besoins en données. Dans ce cas, la requête doit être mise en cache dans Redis ou Memcache et ne pas être exécutée par les utilisateurs.

Pour résoudre le problème avec Using Filesort, nous devons nous assurer que MySQL utilise un INDEX. Vous avez le choix entre plusieurs clés possibles_keys, mais MySQL ne peut utiliser qu'un seul index dans la requête finale. Bien que les index puissent être composites de plusieurs colonnes, l'inverse n'est pas vrai, bien que vous puissiez indiquer à l'optimiseur MySQL les index que vous avez créés.

Indicateurs d’index

L’optimiseur de MySQL utilisera des statistiques basées sur les tables de requêtes pour sélectionner le meilleur index pour l’étendue de la requête. Pour ce faire, il se base sur la logique statistique de son optimiseur intégré, même si avec des choix multiples, cela ne peut pas toujours être correct sans indication. Pour vous assurer que la clé correcte est utilisée (ou non utilisée), utilisez les mots clés FORCE INDEX, USE INDEX et IGNORE INDEX dans votre requête. Vous pouvez en savoir plus sur l'indexation d'index dans le manuel MySQL.

Pour examiner les clés de la table, utilisez la commande SHOW INDEX.

Vous pouvez spécifier plusieurs astuces à utiliser par l'optimiseur, par exemple:

Maintenant que MySQL a l'index_status de la table à utiliser, la requête est résolue.

A côté de EXPLAIN se trouve le mot clé DESCRIBE. DESCRIBE vous permet d’afficher les informations d’une table comme suit:

Ajout d’index

Vous avez créé un index dans MySQL avec la syntaxe de CREATE INDEX. Il y a quelques saveurs d’index. FULLTEXT est utilisé pour la recherche en texte intégral. Il existe ensuite le type UNIQUE pour garantir que les données restent uniques.

Pour ajouter un index à votre table, utilisez la syntaxe suivante, par exemple:

Cela créera un index sur les utilisateurs de la table, qui utilisera les 10 premières lettres de la colonne de nom d'utilisateur, qui est un type de données varchar.

Dans ce cas, toute recherche nécessitant un tri WHERE sur le nom d'utilisateur avec la correspondance dans les 10 premiers caractères serait identique à une recherche de la table entière.

Index composites

Les index ont un effet considérable sur la rapidité de renvoi des données de la requête. Le simple fait de définir une clé primaire et un index unique ne suffit généralement pas: les clés composites constituent le véritable créneau de réglage dans MySQL, qui nécessite le plus souvent une vérification A / B avec EXPLAIN.

Par exemple, si nous devons référencer deux colonnes dans notre condition WHERE, une clé composite serait idéale.

Ici, cette clé est créée sur la colonne de nom d'utilisateur de l'exemple précédent et sur la colonne active, un type de données ENUM indiquant si le compte d'utilisateur est actif. Alors maintenant, quand on interroge les données pour WHERE, le nom d'utilisateur est valide et le compte est actif = 1, l'ensemble de données est maintenant optimisé pour mieux gérer cela.

Quelle est votre MySQL ?

Activez le profilage pour examiner de plus près vos requêtes MySQL. Cela peut être fait au moment de l'exécution via set profiling = 1, puis en exécutant votre requête et en consultant le résultat des profils d'affichage.

Avec PDO, voici un extrait de code qui fait exactement cela:

Si vous n'utilisez pas PDO, vous pouvez faire la même chose avec mysqli:

Cela vous renverra les données de profilage, qui incluront le temps d'exécution dans la deuxième valeur du tableau associatif:

La requête a pris 0,00024300 secondes. C’est assez rapide pour ne pas s’inquiéter. Mais lorsque les chiffres augmentent, nous devons regarder de plus près.

Par exemple, apprenez à connaître votre application. Cochez une constante DEBUG dans le pilote de base de données des couches d'abstraction / infrastructures de votre application, puis commencez à effectuer l'audit en activant un cas de profil et en générant le résultat avec var_dump / print_r. Vous pourrez désormais parcourir et profiler facilement les pages de votre site Web!

Audit complet de votre application

Pour effectuer un audit complet de vos requêtes, activez la journalisation. Certains développeurs avec lesquels j'ai travaillé craignent qu'il ne s'agisse d'un problème à double face, car l'activation de la journalisation affecte légèrement les performances. Les statistiques que vous enregistrez seront donc légèrement inférieures à la réalité. Même si cela est vrai, de nombreux points de repère montrent que la différence n’est pas trop grande.

Pour activer la journalisation dans MySQL version 5.1.6, vous utilisez le journal global log_slow_queries et vous pouvez spécifier un fichier avec slow_query_log_file global. Cela peut être fait à l’invite d’exécution comme suit:

Vous pouvez définir ceci de manière persistante dans le fichier de configuration /etc/my.cnf ou my.ini pour votre serveur.

Après avoir effectué cette modification, vous devez redémarrer le serveur MySQL, par exemple. service mysql redémarrer sur les systèmes Linux.

Dans MySQL 5.6.1, la version la plus récente, log_slow_queries est obsolète et slow_query_log est utilisé à la place. L'activation de TABLE en tant que type de sortie permet une expérience de débogage beaucoup plus agréable et peut être effectuée comme suit dans MySQL 5.6.1 et versions ultérieures:

long_query_time spécifie le nombre de secondes pendant lequel une requête lente est classée. La valeur par défaut est 10 et le minimum 0. Il peut prendre des valeurs en millisecondes en spécifiant un float; ici je l'ai réglé à 1 seconde. Ainsi, toute requête prenant plus d'une seconde va être enregistrée dans le format de sortie TABLE.

Cela se connectera aux tables mysql.slow_log et mysql.general_log dans MySQL.

Pour désactiver la journalisation, la valeur log_output NONE.

log_queries_not_using_indexes est un booléen utile qui, lorsqu'il est activé en conjonction avec le journal de requête lent, signifie que seules les requêtes censées extraire toutes les lignes sont consignées.

Cette option ne signifie pas toujours qu'aucun index n'est utilisé. Par exemple, lorsqu'une requête utilise une analyse d'index complète, celle-ci est consignée car l'index ne limite pas le nombre de lignes.

Connexion en production?

L'activation de la journalisation sur un site de production avec du trafic devra presque toujours être effectuée pendant une courte période, tout en surveillant la charge pour s'assurer qu'elle n'affecte pas le service. Si vous êtes soumis à une charge importante et avez besoin d'une solution urgente, commencez par traiter le problème à l'invite avec SHOW PROCESSLIST ou via la table information_schema.PROCESSLIST directement, par exemple. sélectionnez * dans information_schema.PROCESSLIST ;.

La consignation de toutes les requêtes en production peut vous en dire beaucoup et constitue une bonne pratique à des fins de recherche lorsque vous auditez un projet, mais le laisser fonctionner plusieurs jours de suite ne vous donnera souvent pas plus de données utilisables qu’au mieux 48 heures ( en moyenne, capturez au moins les heures de pointe d'utilisation afin de bien examiner les requêtes et de vous faire une idée de la fréquence).

Remarque: si vous exploitez un site qui connaît des pics de trafic et des périodes de très faible fréquentation (comme un site Web sportif pendant et hors saison), soyez logique avec la manière dont vous envisagez la journalisation. Ne présumez pas que le site fonctionne rapidement. Faites un audit et, surtout, configurez des graphiques.

Journalisation et dig-pt-digest de Percona

Percona propose d’excellents outils, et pt-query-digest est un outil de ligne de commande permettant d’analyser les journaux de requêtes, la liste de processus ou tcpdumps.

Vous pouvez utiliser pt-query-digest des manières suivantes:

Analysez un fichier * .log (issu de votre journalisation de requête lente par exemple):

Rapport sur les requêtes les plus lentes de host1 en temps réel (très utile!):

Utilisez tcpdump pour signaler les requêtes les plus lentes à partir des données du protocole MySQL:

Enfin, nous pouvons enregistrer des données de requête lentes d’un hôte à un autre pour une révision ultérieure. Ici, nous enregistrons le résumé de la requête de slow.log dans host2:

Pour apprendre à utiliser pleinement l'outil pt-query-digest de Percona, lisez la page de manuel.

Représentation graphique de MySQL et des performances du serveur

InnoDB Row Operations

Ce graphique des opérations de ligne InnoDB montre les opérations de ligne effectuées par InnoDB: mises à jour, lectures, suppressions et insertions.

C’est un sujet important et je vais juste en parler suffisamment dans ce guide pour vous permettre de démarrer avec la surveillance MySQL. Toutefois, il est important de noter que la surveillance de tous les services de votre site Web est idéale pour connaître réellement vos performances et vos usages.

Pour ce faire, je vous recommande de configurer une solution basée sur RRDTool telle que Cacti avec une configuration MySQL. Obtenez un modèle pour Cacti des gars de Percona.

Une fois que vous avez configuré Cacti et que vous pouvez commencer à analyser votre application, laissez un peu de temps pour permettre aux graphiques de se constituer.  Après quelques jours, vous commencerez à voir les rythmes de votre trafic jour et nuit et à voir à quel point le serveur est vraiment occupé.

Si vous recherchez des alertes et des déclencheurs automatisés, envisagez de configurer monit, un moniteur proactif à code source ouvert pour les systèmes Unix. Avec monit, vous pouvez créer des règles pour votre serveur et vous assurer que vous êtes alerté lorsque la charge augmente, afin que vous puissiez la détecter pendant qu'elle se produit.

Journal de requête lent

L'enregistrement de toutes les requêtes lentes qui prennent plus d'une seconde à terminer peut nous dire quelque chose, mais il est également important de savoir quelles requêtes s'exécutent des centaines de fois. Même si l'exécution de ces requêtes est courte, la surcharge des requêtes les plus lourdes pèse lourdement sur le serveur.

C’est la raison pour laquelle le fait de rester actif lorsque vous mettez à jour quelque chose et le mettez en ligne est le moment le plus crucial pour tout nouveau travail ou modification de base de données. Mes équipes ont toujours pour politique de ne jamais synchroniser les modifications apportées à la base de données de fonctionnalités après un mercredi sur un projet réel. Cela doit être fait au début de la semaine, au plus tard mardi, afin que toutes les équipes puissent surveiller et apporter un soutien en conséquence.

Avant de mettre en ligne de nouvelles requêtes, vous devez effectuer une analyse comparative avec un outil de test de charge tel que ab. Lorsque vous exécutez le test de performance, vous devez afficher SHOW PROCESSLIST, activer la journalisation et effectuer une surveillance à l'aide d'outils système tels que top, free et iostat. Il s'agit d'une étape cruciale avant de placer une nouvelle requête dans une production en direct. Mais ce n’est pas un test à 100% d’acide, car le trafic réel peut se comporter différemment d’un repère calculé.

Pour comparer avec ab, assurez-vous que le package est installé, par exemple:

Maintenant, vous pouvez commencer par tester votre application, par exemple:

Le -k signifie maintenir en vie la connexion et le -c 350 est le nombre de connexions simultanées, c’est-à-dire le nombre de personnes / clients qui vont accéder au site en même temps. Enfin, le -n 20000 est le nombre de requêtes qui seront adressées à my-domain.com.

Donc, en exécutant la commande ci-dessus, vous frapperez http://my-domain.com/ avec 350 connexions simultanées jusqu’à ce que 20 000 demandes soient satisfaites, en utilisant l’en-tête Keep Alive.

Une fois les 20 000 demandes terminées, vous recevrez un retour d'informations sur les statistiques. Cela vous indiquera la performance du site sous le stress que vous lui avez attribué lors de l'utilisation des paramètres ci-dessus. C'est un bon moyen de savoir de manière automatisée si votre requête a changé quelque chose.

Analyse comparative chaud / froid

Le montant de la demande et la charge du serveur ont un impact considérable sur les performances, ce qui peut affecter le temps de requête. Dans l’ensemble, vous devez activer le journal de requête lent pour qu’il capture ce problème en production et, en règle générale, vous devez vous assurer que toutes les requêtes s’exécutent en fractions de milliseconde (0,0xx ou plus rapide) sur un serveur inactif.

L'implémentation de Memcache aura un impact considérable sur vos exigences de charge et sera utilisée pour décharger sérieusement les ressources qui étaient en train d'être traitées. Assurez-vous d’utiliser Memcached de manière efficace et comparez votre application avec un cache chaud (préchargé avec des valeurs) et un cache froid.

Pour éviter de passer à la production avec un cache vide, un script de préchargement est un bon moyen de garantir que le cache sera lu et que vous ne recevrez pas un grand nombre de demandes toutes en même temps lors du retour d'un temps d'arrêt en raison de pannes de surcapacité.

Correction de requêtes lentes

Donc, après avoir activé la journalisation, vous avez maintenant trouvé des requêtes lentes dans votre application. Allons les réparer! À titre d'exemple, je vais illustrer divers problèmes courants que vous allez rencontrer et la logique pour les résoudre.

Si vous n’avez pas encore trouvé de requêtes lentes, vérifiez peut-être quels sont vos paramètres pour long_query_time si vous utilisez la méthode de consignation des requêtes. Sinon, après avoir vérifié toutes vos requêtes avec profilage (set profiling = 1), dressez une liste des requêtes prenant plus de fractions de milliseconde (0,000 x secondes) et commençons par ces tâches.

Problèmes communs

Voici six problèmes courants rencontrés lors de l'optimisation de requêtes MySQL:

1. ORDER BY en utilisant filesort.

Il est impossible d'éviter le tri de fichiers à cause du nom ORDER BY. Quelle que soit la permutation d'index que vous utilisez, le mieux que vous obtiendrez sera Utiliser où; Utilisation de Filesort dans votre colonne Extra. Pour optimiser cela, enregistrez le résultat dans Memcache ou effectuez une commande dans la couche logique de votre application.

2. Utiliser ORDER BY sur WHERE et un LEFT JOIN

ORDER BY a un impact significatif sur les requêtes. Par exemple, ce qui suit est une base LEFT JOIN d’une table produits et la table des catégories au moyen d’un code d’entier. Lorsque la commande est supprimée, le tri de fichiers l'est également.

Lorsque cela peut être évité, essayez de ne pas utiliser ORDER BY. S'il doit absolument être utilisé, commandez uniquement sur une clé d'index.

3. Order By sur une colonne temporaire

Ne le fais pas. Si vous avez besoin d'agréger vos résultats, faites-le dans votre logique d'application. ne faites pas le filtrage ou la commande sur une table temporaire dans MySQL. Cela demandera beaucoup de ressources.

4. Ne pas utiliser d'index FULLTEXT

L'utilisation d'une requête LIKE est de loin le moyen le plus lent d'effectuer une correspondance en texte intégral sur vos données. Implémentez une recherche en texte intégral et profitez des avantages de cette brillante fonctionnalité de MySQL:

5. sélection d’un nombre considérable de lignes inutilement

L'oubli d'une limite sur une requête peut modifier considérablement le temps de recherche sur de grands ensembles de données (plus d'un million de lignes).

6. rejoindre trop au lieu de juste faire un composite table ou une vue

Quand il y a trois ou quatre niveaux de LEFT JOIN, vous devriez vous demander: 'Est-ce que je fais bien cela?' Si vous avez un argument raisonnable sur la raison pour laquelle cette requête doit l'être, par exemple, elle n'apparaît que dans un écran d'administration faiblement sollicité ou dans l'utilisation d'une vue statistique plus grande pouvant être mise en cache, puis continuez. Toutefois, si vous devez accéder fréquemment à vos données avec un grand nombre de jointures, vous devez vous rendre compte de l’utilité de la composition des colonnes dans une nouvelle table ou de la création d’une vue.

Conclusions

Nous avons discuté des principes fondamentaux d'optimisation et des outils dont nous disposons pour effectuer le travail. Nous devons auditer avec le profilage, utiliser l'outil pt-query-digest et EXPLAIN d'abord pour voir ce qui se passe réellement, puis à partir de là nous pourrons mieux concevoir.

Nous avons également examiné plusieurs exemples de cas et les pièges courants que vous pouvez rencontrer lorsque vous utilisez MySQL. En utilisant l'indexation des index, nous pouvons nous assurer que MySQL sélectionne les bons index pour le travail et ne soit pas confus, surtout s'il y a plusieurs requêtes sur la même table. Pour continuer votre lecture sur ce sujet, consultez le blog du projet Percona et MySQL Performance pour plus d'informations.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.