Comment profiler les requêtes SQL pour de meilleures performances

Chez Servebolt, nous vivons et respironsla performance .

Les performances de la base de données ne font pas exception.

L'exécution d'une requête inefficace après qu'un visiteur du site Web ait cliqué sur un lien dégradera considérablement l'expérience de l'utilisateur .Ils devront attendre toute la durée de l'exécution de la requête lente, qui peut prendre plusieurs secondes, avant toute autre action, telle que le rendu de la page. Ce temps d'attente inclut non seulement le temps nécessaire à l'exécution de la requête, mais également tout temps supplémentaire nécessaire au prétraitement et au post-traitement. Par conséquent, une requête mal conçue peut ralentir considérablement les performances globales d'un site Web, ce qui entraîne une expérience utilisateur frustrante.

Time to First Byte (TTFB) est un moyen de mesurer le temps qu'il faut pour que le premier octet de données soit reçu après qu'un utilisateur a fait une demande à un site Web.C'est également une mesure clé utilisée par les moteurs de recherche pour évaluer les sites. Lorsqu'une requête lente est déclenchée, cela affectera négativement le TTFB. Plus la requête lente prend de temps à s'exécuter, plus le TTFB sera élevé, ce qui entraînera des performances globales du site Web plus lentes et une expérience utilisateur moins satisfaisante.

Dans ce guide, nous vous expliquerons comment profiler les requêtes SQL - un élément crucial pour maintenir les performances des applications Web qui s'appuient sur les réponses de la base de données. Il s'agit d'un processus qui pose les bases pour pouvoir ensuite commencer à travailler sur l'optimisation de ces requêtes pour améliorer leurs performances.

Comprendre le profilage des requêtes SQL

Lorsque vous développez une application Web et qu'elle commence à fonctionner à plus grande échelle, les requêtes SQL qui s'exécutaient correctement auparavant peuvent entraîner des problèmes de performances. De manière générale, il y a généralement un nombre croissant de requêtes exécutées sur une quantité croissante de données avec un nombre croissant de requêtes par seconde. Et lorsque les performances en souffrent, il en va de même pour l'expérience de vos utilisateurs lorsqu'ils interagissent avec votre site, logiciel ou service.

Le profilage des requêtes est un moyen d'analyser les requêtes de base de données, d'évaluer leurs performances et d'identifier les problèmes potentiels.

En analysant et en identifiant ces requêtes problématiques, vous pouvez apporter des améliorations spécifiques qui peuvent faire une différence mesurable dans les performances de leur base de données. Cela permettra à son tour d'améliorer l'évolutivité à l'avenir, ainsi que la satisfaction globale des clients, car les applications et les sites seront plus réactifs.

MariaDB (et MySQL) fournissent plusieurs outils et techniques pour le profilage des requêtes, que nous aborderons dans cet article. Une fois les requêtes lentes identifiées , la prochaine étape sera de les optimiser. Ce processus comprend l'identification de la cause première du problème et la modification de la structure des requêtes pour améliorer leur efficacité.

Comment profiler les requêtes SQL (7 méthodes)

Commençons par décomposer les différents outils et techniques disponibles pour identifier les requêtes lentes et inefficaces afin que vous sachiez où concentrer vos efforts d'amélioration :

1 – La commandeEXPLAIN EXTENDED

L'un des outils qui peut être utilisé pour analyser vos requêtes SQL est la commandeEXPLAIN .

En exécutant la commande EXPLAIN sur une requête, vous pouvez voir comment la requête est exécutée, y compris les index utilisés et le nombre de lignes examinées.

EXPLAIN SELECT * FROM orders

JOIN customers ON orders.customer_id = customers.customer_id

WHERE customers.name = 'John Smith';

Lorsque vous exécutez la commande EXPLAINsur une requête, elle renvoie un ensemble de résultats avec plusieurs colonnes, notamment :

• id: L'identifiant unique de la requête dans le plan d'exécution
• select_type: Le type de la requête, tel que SIMPLE ou SUBQUERY
• table: la table interrogée
• type: Le type de jointure utilisé, tel que JOIN ou INDEX
• possible_keys: Les index que MariaDB ou MySQL auraient pu utiliser pour traiter la requête
• key: L'index que MariaDB ou MySQL a réellement utilisé pour traiter la requête
• key_len: La longueur de la clé qui a été utilisée
• rows: Le nombre de lignes estimées par MariaDB ou MySQL qui seront examinées pour la requête

Extra: contient des informations supplémentaires sur la requête, par exemple si une analyse complète de la table a été effectuée ou si une table temporaire a été utilisée.

En analysant la sortie de la commandeEXPLAIN, vous êtes généralement en mesure d'identifier les goulots d'étranglement potentiels des performances, tels qu'une indexation médiocre, des types de jointure sous-optimaux ou un nombre élevé de lignes examinées.

Par exemple, si la colonne de type affiche "ALL" au lieu de "index", la requête effectue une analyse complète de la table, ce qui entraînera certainement un ralentissement des performances. Si la colonne clé est NULL, alors MySQL n'utilise aucun index, ce qui sera également lent. Si la colonne des lignes a une valeur élevée, cela signifie que de nombreuses lignes sont en cours d'examen, ce qui entraîne une dégradation supplémentaire des performances.

Nous préférons utiliser la variante EXPLAIN EXTENDED pour aider à fournir des informations supplémentaires.

Remarque : bien que cela soit obsolète dans MySQL, il est toujours disponible dans MariaDB.

En utilisant l'option EXTENDED, vous pourrez voir des informations utiles telles que le nombre de lignes examinées, le nombre de lignes renvoyées, des informations sur le type de JOIN utilisé, l'ordre des tables analysées, les index utilisés et la durée la requête a pris pour être exécutée.

Voici à quoi ressemble l'utilisation de la commande EXPLAIN EXTENDED :

EXPLAIN EXTENDED SELECT * FROM your_table WHERE column_name = 'value';

Dans cet exemple, la commande EXPLAIN affichera une liste des étapes que la base de données suivra pour exécuter la requête, ainsi qu'une liste des ressources qu'elle utilisera.

En utilisant cette commande, vous pourrez plus facilement repérer les goulots d'étranglement dans la requête, ce qui vous permettra d'apporter les modifications nécessaires pour atténuer cela et accélérer les performances de la requête.

Par exemple, l'utilisation de la commande EXPLAIN EXTENDED peut aider à identifier la nécessité d'ajouter des index, d'optimiser les conditions JOIN et de limiter le nombre total de lignes renvoyées par la requête.

Vous devez également vous assurer que vous avez désactivé la mise en cache des requêtes lors de ces tests et optimisations pour vous assurer d'obtenir des résultats précis. Pour ce faire, exécutez d'abord cette commande lorsque vous connectez votre client.

SET SESSION query_cache_type=0;

Une fois que vous avez apporté ces modifications à votre requête, testez à nouveau ses performances pour identifier le degré d'amélioration réalisé (le cas échéant). N'oubliez pas que, comme pour tout profilage et optimisation d'une requête, le processus est itératif. Attendez-vous à utiliser la commande EXPLAIN EXTENDED, suivie d'un test de performances, plusieurs fois.

2 – La commandeEXPLAIN ANALYZE

Cette commande est utilisée pour analyser le plan d'exécution d'une requête et renvoyer des métriques de performances telles que le temps réel d'exécution de la requête et le nombre de lignes réellement examinées. En analysant les résultats de la commande EXPLAIN ANALYZE, vous pouvez identifier tout goulot d'étranglement potentiel dans l'exécution de la requête, comme un manque d'index ou un nombre élevé de lignes à examiner.

3 – Le journal des requêtes lentes

Il s'agit d'une fonctionnalité intégrée à MariaDB (et MySQL) qui enregistre toutes les requêtes dont l'exécution prend plus de temps qu'un certain temps. Le journal des requêtes lentes peut être configuré pour consigner les requêtes qui prennent plus de temps qu'un seuil spécifique, comme une seconde.

Chez Servebolt, le journal des requêtes lentes enregistre toutes les requêtes dont l'exécution prend plus d'une seconde. En effet, la plupart des requêtes doivent s'exécuter en quelques fractions de seconde. Dans le contexte d'une application Web, telle qu'un site exécutant WordPress, le chargement d'une seule page nécessite entre 10 et 100 requêtes de base de données, qui doivent toutes être exécutées de manière séquentielle avant que la page puisse être compilée en HTML et renvoyée à l'utilisateur.

La configuration actuelle de Servebolt Cloud conserve les journaux de requêtes lentes sur un serveur de journaux global. Si le besoin s'en fait sentir, vous pouvez simplement contacter notre équipe d'assistance, et nous filtrerons le fichier pour les journaux pertinents et vous fournirons la sortie.

Dans vos propres environnements, vous pouvez activer le journal des requêtes lentes en ajoutant les lignes suivantes à votre fichier de configuration MariaDB ou MySQL (my.cnf ou my.ini) :

log_slow_queries = /path/to/slow.log

long_query_time = 1

4 – Plan d'explication visuel

Un plan d'explication visuel fournit une représentation graphique de la sortie de la commande EXPLAIN, ce qui facilite la compréhension de l'exécution d'une requête et la détection de tout problème de performances.

Remarque : Les plans d'exécution visuels sont utiles lorsque vous êtes en train de développer des applications Web.

Au lieu d'une sortie en texte brut, il affiche l'exécution de la requête dans une structure arborescente , chaque nœud représentant une table, un index ou une opération, et les connexions entre eux décrivent l'ordre des opérations.

Différents outils, tels que MySQL Workbench et EXPLAIN Analyzer, peuvent générer des plans d'exécution visuels et offrent une interface interactive pour naviguer dans le plan d'exécution et examiner chaque opération en détail.

Par exemple, dans MySQL Workbench, générer un plan d'explication visuel est aussi simple que d'exécuter la requête et de cliquer sur le bouton «Expliquer le plan » dans l'onglet des résultats.Celui-ci présente une représentation graphique du plan d'exécution de la requête, ainsi que des informations détaillées sur chaque opération. Cela vous permet d'identifier les problèmes de performances, puis d'optimiser la requête si nécessaire.

5 – Le tuner MySQL

MySQL Tuner est un script qui vérifie les performances et la configuration d'un serveur de base de données et fournit des recommandations d'amélioration. Il fournit un résumé de l'état actuel du serveur, y compris des informations telles que le nombre total de requêtes, le nombre de requêtes lentes et l'utilisation actuelle du pool de mémoire tampon.

Il peut également être utilisé pour vérifier divers autres paramètres, tels que la version de la base de données, le moteur de stockage utilisé et la configuration du cache de requêtes, et fournit des recommandations pour optimiser ces paramètres en fonction de la charge de travail actuelle.

L'une des principales différences avec d'autres outils est qu'il s'agit d'un outil de ligne de commande qui peut être exécuté sur le serveur lui-même ou à distance, ce qui facilite l'automatisation du processus de surveillance et d'optimisation des performances de la base de données.

Remarque : Si votre application Web (et votre base de données) sont déjà hébergées dans le Cloud Servebolt, c'est quelque chose dans lequel notre équipe est spécialisée et est capable de faire mieux que n'importe quelle recommandation qu'un outil pourrait fournir.

6 - Profileurs de requêtes

Il existe des profileurs de requêtes tiers qui peuvent être utilisés pour profiler les requêtes SQL, tels que MariaDB Enterprise Query Analyzer , Dataedo et Percona Toolkit . Les profileurs de requêtes tiers peuvent fournir des fonctionnalités et des fonctionnalités supplémentaires par rapport aux outils intégrés disponibles dans MariaDB (ou MySQL).

Remarque : Les profileurs de requêtes sont utiles lorsque vous êtes en train de développer des applications Web.

Par exemple, ils peuvent offrir des informations plus détaillées sur les performances des requêtes, telles que les temps d'exécution et les temps d'attente des verrous, et peuvent fournir une visualisation des données d'une manière qui n'est pas possible avec les outils intégrés.

Si les outils intégrés sont suffisants pour vos besoins, il n'est pas nécessaire d'utiliser des profileurs de requêtes tiers. Toutefois, si vous avez besoin d'informations plus détaillées ou de fonctionnalités avancées, il peut être utile d'envisager un profileur tiers.

7 – Profilage avec des outils de surveillance

Il existe également un certain nombre d'outils de surveillance, tels que Prometheus, Grafana et Nagios, qui peuvent être utilisés pour profiler les requêtes et surveiller les performances de vos bases de données.

Prometheus est un système de surveillance efficace qui peut collecter, stocker et interroger des données de métriques, vous permettant d'obtenir des informations précieuses en temps réel.Il s'intègre à MariaDB (et MySQL) pour stocker les métriques recueillies et est livré avec Grafana pour une visualisation efficace.

Grafana est un puissant outil d'analyse open source qui peut être utilisé pour surveiller et visualiser les données recueillies auprès de Prometheus.La configuration de tableaux de bord et d'alertes personnalisés vous permet de garder un œil sur les performances de votre base de données en temps réel.

Nagios vous aide à garder un œil sur la santé de votre base de données à tout moment.Il peut être configuré pour surveiller les ressources clés telles que le processeur, la RAM et l'espace disque, tout en gardant une trace des autres services et périphériques réseau. Comme il est hautement configurable, c'est un excellent outil pour la surveillance proactive des requêtes de base de données.

À l'aide de ces outils de surveillance de serveur, vous pouvez suivre les problèmes de performances et agir rapidement, ce qui vous permet de vous assurer que votre serveur de base de données fonctionne correctement.

Techniques courantes d'optimisation des requêtes

Plusieurs techniques courantes d'optimisation des requêtes peuvent être utilisées pour améliorer les performances des requêtes SQL :

1 – Indexation

Les index sont un moyen d'accélérer les requêtes, en particulier celles qui utilisent des filtres(WHERE).L'utilisation d'index génère des structures de données dans votre moteur de base de données (MariaDB ou MySQL) en dehors de tables spécifiques et pointe vers les données que vous essayez d'interroger. Nous n'entrerons pas trop dans les détails dans cet article, car l'utilisation d'index pour améliorer les requêtes de base de données justifie un article à part entière - quelque chose que nous prévoyons de couvrir à l'avenir.

Par exemple, considérez une grande table appelée "commandes" qui contient des millions de lignes de données, y compris des informations telles que l'ID de commande, l'ID client et la date de commande. Si une requête est exécutée pour récupérer toutes les commandes passées par un client spécifique sans index sur la colonne d'ID client, MariaDB devra analyser l'intégralité de la table pour localiser les données pertinentes. Cela peut prendre beaucoup de temps et de ressources, en particulier pour les grandes tables.

D'une manière générale, chaque fois que vous êtes sûr d'exécuter une requête spécifique de manière répétée et de lire les problèmes de performances, la création d'un index (ou de plusieurs) peut être la bonne approche pour accélérer cette requête.

Dans le contexte de WordPress, c'est très courant. De nombreux plugins sont créés par des développeurs qui (par commodité) utilisent des tables génériques partagées sans utiliser d'index. De ce fait, c'est aussi un domaine où il y a souvent des gains de performances très significatifs.

Pour afficher tous les index qui existent sur une table particulière,

Vous pouvez afficher tous les index qui existent sur une table spécifique en utilisant SHOW INDEX FROM - comme dans l'exemple ci-dessous pour la table wp_postmeta :

MariaDB [db_name] > SHOW INDEX FROM wp_postmeta;

Dans un scénario, nous avons récemment créé deux index pour une table wp_postmeta : sb_postid_metakey et sb_postid_metakey_metaval.

Ces index ont été ajoutés en examinant les principales requêtes lentes et en constatant qu'elles étaient toutes relativement similaires par la caractéristique d'être des instructions SELECT qui filtrent à l'aide de WHERE en plus de nombreuses conditions de comparaison (AND/OR). En voyant cela, j'ai examiné les index actuels de la table utilisée et exécutéEXPLAIN EXTENDED sur la requête pour valider davantage mon approche.

La requête fonctionnait principalement et utilisait la table wp_postmeta en utilisantJOIN.En fonction de l'ordre dans lequel cela se produisait, l'ajout de ces index permettrait à MariaDB (ou MySQL) d'obtenir sa réponse à partir des index au lieu d'analyser la table entière avec toutes ses lignes.

CREATE INDEX sb_postid_metakey ON wp_postmeta (post_id, meta_key);

CREATE INDEX sb_postid_metakey_metaval ON wp_postmeta (post_id, meta_key, meta_value);

Il s'agit d'une combinaison de « comprendre les choses » en utilisant les outils dont vous disposez (comme indiqué ci-dessus), ainsi que la connaissance des types de données et du contenu de la base de données. Cela ne fonctionne en aucun cas toujours; même quand c'est le cas, cela n'entraîne pas toujours une amélioration des performances de 500 %. Avoir un index énorme peut finir par être plus lent que d'analyser toutes les lignes, donc les requêtes doivent être testées avant et après l'application des index pour être sûr.

Remarque : lorsque vous essayez de tester les vitesses d'indexation, vous souhaiterez désactiver la mise en cache des requêtes pour la session, en utilisant :

SET SESSION query_cache_type=0;

Dans ce cas, avant d'utiliser les index, la requête prenait 10,437 secondes à s'exécuter. Et après avoir créé les deux index, la même requête a pris [# de secondes].

2 – Réduire l'accès aux données

Réduire l'accès aux données , c'est-à-dire minimiser le nombre de lignes et de colonnes auxquelles il faut accéder pour exécuter une requête.Cela peut être réalisé en filtrant les données récupérées par la requête, en utilisant des index et en partitionnant de grandes tables. Bien que ce ne soit pas quelque chose que la plupart des gens auront besoin (ou pourront) faire, c'est un point essentiel à garder à l'esprit lors de la conception de requêtes de base de données à partir de zéro.

Par exemple, si une requête de base de données recherche des données sur un utilisateur à des fins de connexion, la requête doit être LIMIT 1, car il ne devrait clairement jamais y avoir plus d'une donnée d'utilisateur requise.

Remarque : cela concerne davantage la conception de la base de données que l'optimisation.Bien qu'important pour maintenir les performances, cet effort est plus pertinent pour les développeurs de plugins (dans le contexte de WordPress) que pour la majorité des utilisateurs finaux.

N'oubliez pas qu'avant de tester les vitesses après avoir apporté des modifications à l'accès aux données, vous devez vous assurer que vous avez désactivé la mise en cache des requêtes en exécutant la commande suivante :

SET SESSION query_cache_type=0;

3 – Utilisation du partitionnement des données

En partitionnant les données en blocs plus petits, les bases de données deviennent plus efficaces et prennent moins de temps à gérer. Cette stratégie peut aider à réduire le temps consacré aux processus de maintenance tels que les sauvegardes et les mises à jour, ainsi qu'à limiter la quantité de données à gérer. Dans l'ensemble, cela contribue à améliorer les performances et à optimiser l'utilisation des ressources.

Pour partitionner des données dans une base de données, vous pouvez suivre ces étapes :

1. Lors de la sélection d'une table à partitionner, assurez-vous d'en choisir une qui contient une grande quantité de données et qui gagnerait à être divisée. Cela vous aidera à optimiser votre système et à améliorer les performances des requêtes.
2. Choisir la bonne méthode de partitionnement pour votre base de données est crucial. Vous pouvez choisir entre plage, liste, hachage ou partitionnement par clé, en fonction de la structure de vos données et des requêtes que vous prévoyez d'exécuter. Assurez-vous de choisir celui qui correspond le mieux à vos besoins pour des performances et des résultats optimisés.
   
   1. Le partitionnement par plage est le choix idéal lorsque vous avez des données qui peuvent être divisées en certaines plages.Par exemple, si vous avez une table avec des données pour plusieurs années, vous pouvez créer une partition de plage pour mieux l'organiser. Il peut être basé sur la date ou la valeur numérique de la colonne en question.
   2. Le partitionnement de liste est une technique efficace pour gérer des données qui peuvent être facilement séparées en différents groupes selon un paramètre particulier.Par exemple, vous avez un tableau avec des informations sur les employés classées par département ; cela nécessite l'utilisation du partitionnement de liste.
   3. Le partitionnement par hachage est une stratégie efficace pour organiser les données en clusters de taille égale en fonction de la valeur de hachage d'une colonne spécifique.Cela permet une distribution uniforme des données sur plusieurs partitions, ce qui en fait un excellent choix pour une distribution efficace des données.
   4. Le partitionnement par clé est similaire au partitionnement par hachage, mais la principale différence est qu'il utilise une valeur de colonne spécifique comme base pour diviser les données en différents groupes.Cela en fait un choix idéal pour les ensembles de données qui peuvent être divisés en groupes distincts en fonction d'un identifiant unique ou d'une clé naturelle.
3. En créant une table partitionnée, vous pouvez efficacement diviser la table d'origine en tables plus petites. Ceci est réalisé en ajoutant une clause de partitionnement dans l'instruction CREATE TABLE, où vous spécifiez la méthode et les conditions souhaitées pour la segmentation. Cela peut aider à améliorer les performances des requêtes et à rendre la gestion des données plus efficace.
4. Vous pouvez rapidement copier des données de la table d'origine vers la table nouvellement partitionnée à l'aide de l'instruction INSERT INTO… SELECT. Cela remplira facilement votre table partitionnée avec toutes les informations pertinentes.
5. Les applications doivent maintenant être reconfigurées pour tirer parti de la table partitionnée. Celle-ci remplacera la table d'origine et rendra vos applications plus efficaces.
6. Avant d'exécuter un test pour évaluer l'amélioration potentielle des performances, il sera essentiel de désactiver d'abord la mise en cache des requêtes en exécutant la commande : SET SESSION query_cache_type=0;
7. Pour vous assurer que votre table partitionnée fonctionne correctement, il est important de surveiller de près ses performances. Si vous remarquez des problèmes, ajuster les conditions de partitionnement ou passer à une autre méthode peut vous aider. Un suivi régulier de vos cloisons vous aidera à maximiser leur potentiel.

Remarque importante sur les mises à niveau de script et les tables partitionnées

Bien que le partitionnement des bases de données puisse faire une différence positive en termes d'efficacité, il est important de garder à l'esprit les problèmes potentiels causés par l'exécution de scripts de mise à niveau pour modifier le schéma de la base de données. Il est essentiel que les tables partitionnées soient prises en compte lors du scriptage de ces mises à niveau. Si les tables partitionnées ne sont pas prises en compte dans les scripts de mise à niveau, il peut y avoir des problèmes potentiels qui entraîneront presque certainement un dysfonctionnement du site.

Par exemple, si un script est créé pour ajouter une nouvelle colonne à une table partitionnée, il peut ne modifier qu'une seule partition, créant des incohérences et des problèmes dans les données. De même, si un script de mise à niveau est créé pour ajouter un index à une table partitionnée, il ne peut générer l'index que sur une partition, ce qui ralentit les performances et produit des résultats incohérents.

Pour éviter de tels problèmes, les scripts de mise à niveau doivent être conçus pour prendre en compte les tables partitionnées. Cela peut impliquer d'exécuter le script sur chaque partition individuellement ou de réviser les scripts pour qu'ils fonctionnent avec des tables partitionnées. Il est également important d'effectuer des tests approfondis pour s'assurer que le processus de mise à niveau ne génère pas de problèmes inattendus ni de perte de données.

4 – Redis

Pour les clients de Servebolt, Redis est un module complémentaire (payant) qui peut aider à l'optimisation des requêtes.

Redis (parfois appelé Remote Dictionary Server) est une solution open source qui stocke les données en mémoire et peut être utilisée pour la mise en cache, une base de données ou même comme courtier de messages. Il peut être intégré à une base de données pour améliorer les performances, agissant comme un intermédiaire efficace entre l'application et la base de données.

Il travaille à améliorer les performances et les temps de réponse des applications en réduisant la charge sur la base de données. Cela se fait en stockant les données fréquemment utilisées dans Redis au lieu de la base de données pour chaque demande, ce qui permet de gagner un temps considérable.

En configurant correctement le plugin, Redis peut être utilisé avec une base de données pour optimiser l'exécution des requêtes. Lorsque les données requises ne sont pas présentes dans Redis, l'application les récupère de la base de données et les stocke dans Redis pour une utilisation future. Cela rend la récupération des données beaucoup plus rapide et plus efficace.

En utilisant cette approche, l'application peut bénéficier de l'accès rapide en mémoire de Redis et également stocker et accéder aux données de la base de données selon les besoins.

N'oubliez pas que si vous implémentez Redis pour la première fois, vous devrez désactiver la mise en cache des requêtes avant d'exécuter des tests de performances. Pour cela, utilisez la commande :

SET SESSION query_cache_type=0;

Conclusion

L'écosystème MariaDB et MySQL dispose d'un large éventail d'outils et de méthodes pour faciliter la découverte des goulots d'étranglement dans les exécutions de requêtes de base de données, vous permettant d'améliorer les performances de vos applications Web.

Des ralentissements sont susceptibles de se produire tout au long de la durée de vie de toute application. Essayer de les éviter est formidable, mais vous devez finalement savoir où chercher lorsque vous commencez à diagnostiquer des problèmes de performances. Selon la taille et la nature des bases de données que vous exécutez, il s'agit d'un processus itératif qui nécessite une surveillance continue, un dépannage et une amélioration continue pour maintenir vos bases de données à un niveau élevé.