Les mauvaises performances de la base de données sont une épine dans le pied de chaque DBA. Et il n'est pas toujours facile d'isoler la cause profonde des problèmes de performances, ce qui ne fait qu'ajouter au stress.
Le réglage de vos bases de données SQL Server est un excellent moyen de résoudre certains de vos problèmes de performances, mais il n'est pas toujours évident de commencer le processus d'optimisation. Si vous excluez l'espace disque, la mémoire et d'autres tueurs de performances réseau et matérielles, et que les performances de votre serveur SQL sont toujours à la traîne, il est temps de creuser dans vos requêtes.
Les requêtes non optimisées peuvent entraîner une myriade de problèmes de performances pour vos systèmes. Du bon côté, quelques erreurs de requête courantes sont responsables de l'essentiel de la dégradation des performances de la base de données.
Si vos requêtes souffrent de l'un de ces six problèmes, préparez-vous à un sérieux réglage des performances.
Requête de problème n° 1 :expressions similaires avec caractères génériques de début
Les caractères génériques en tête empêchent MySQL d'utiliser les index, forçant une analyse complète de la table même si vous avez indexé un champ dans la table. L'analyse de toutes les lignes d'une table ralentit considérablement la livraison des résultats de votre requête. Par conséquent, éliminez le caractère générique de début pour améliorer l'efficacité.
Requête de problème n° 2 :colonnes non indexées utilisées dans les clauses "Où" et "Grouper par"
L'indexation des colonnes permet de renvoyer plus rapidement les résultats de la requête, car elle élimine le besoin d'analyses complètes de la table. L'indexation aide également à trier les enregistrements lorsqu'ils sont renvoyés et garantit que ces enregistrements sont identifiables de manière unique, ce qui est particulièrement utile dans les tableaux de plus de 10 lignes.
Pour un peu de perspective, envisagez d'exécuter une instruction « expliquer » dans votre analyse de requête avant et après l'indexation. Cela vous donnera une idée du nombre de lignes de numérisation que vous venez d'enregistrer.
Requête de problème n° 3 : instructions similaires utilisant l'opérateur "ou" au lieu d'une clause d'union
L'exécution de requêtes à l'aide de l'opérateur de comparaison "ou" sur des champs ou des colonnes d'une table peut être utile, mais l'application trop fréquente de "ou" dans une clause "où" est une autre voie rapide vers une analyse complète de la table.
Une clause d'union peut accélérer l'exécution de la requête SQL, en particulier si différents index optimisent chaque côté de la requête. Essentiellement, l'opérateur d'union prend les résultats de deux requêtes indexées rapides et les fusionne en une seule.
Requête problématique n° 4 : recherches avec caractères génériques
Si vous êtes coincé dans une situation où vous devez effectuer une recherche avec des caractères génériques mais que vous ne voulez pas perdre en performances, essayez d'utiliser une recherche en texte intégral MySQL. Les recherches en texte intégral sont considérablement plus rapides que la recherche avec des caractères génériques, et vous bénéficiez en plus de résultats plus pertinents lorsque vous effectuez des recherches dans d'énormes bases de données.
Requête de problème n° 5 :schéma de base de données non optimisé
Vous ne pouvez améliorer les performances des requêtes SQL que si vous n'optimisez pas également le schéma de votre base de données. Voici quelques conseils d'amélioration :
Normaliser les tableaux
La redondance des données nuit aux performances, assurez-vous donc de ne représenter un fait qu'une seule fois dans la base de données. Par exemple, si vous référencez un client dans plusieurs tables, n'utilisez qu'une seule fois "nom_client", puis utilisez "ID_client" pour les références suivantes.
Utiliser des types de données optimaux
Quelques points importants à retenir concernant les types de données :
- Plus c'est court, mieux c'est lors de la conception de tableaux. Par exemple, utilisez le type de données "TINYINT" pour le champ "user_id" pour une table d'utilisateurs système avec moins de 100 utilisateurs.
- Utilisez un type de données "date_time" si un champ attend une valeur de date afin que vous n'ayez pas à convertir les enregistrements au format de date après coup.
- MySQL fonctionne mieux avec des valeurs entières qu'avec des types de données texte, y compris varchar.
Évitez les valeurs nulles
Les valeurs nulles dans une colonne peuvent nuire aux résultats de votre requête, vous devrez peut-être attribuer une valeur par défaut pour les champs où les enregistrements ne nécessitent pas de valeur obligatoire.
N'utilisez pas trop de colonnes
Les tables larges (plus de 100 colonnes) nécessitent beaucoup de CPU et de ressources pour être traitées. À moins que vous ne deviez absolument inclure un tableau large, il est préférable de le diviser en tableaux plus petits et logiques.
Optimiser les jointures
Les instructions SQL avec trop de jointures (et des jointures avec trop de tables) affectent négativement les performances. Ne visez pas plus de 12 jointures pour chaque requête.
Requête problématique n° 6 :requêtes MySQL non mises en cache
Les sites Web et les applications qui effectuent de nombreuses requêtes sélectionnées bénéficieront de la mise en cache des requêtes MySQL. La mise en cache des requêtes MySQL accélère les performances lors des opérations de lecture, car elle met en cache la requête de sélection avec l'ensemble de données résultant et récupère de la mémoire (et non du disque) si la requête est exécutée plusieurs fois.
Le réglage des performances est essentiel pour maintenir la haute disponibilité de vos bases de données SQL Server et garantir la satisfaction de vos utilisateurs finaux. Mais malheureusement, il n'est pas toujours immédiatement évident où le réglage est le plus nécessaire. Si vous avez éliminé les sources évidentes de réseau et de matériel pour les problèmes de performances, concentrez-vous sur vos requêtes.
Si vous travaillez en tant que DBA depuis un certain temps, vous avez probablement rencontré une (ou toutes) ces requêtes problématiques. Maintenant que vous savez ce qu'il faut rechercher, soyez proactif dans votre initiative d'amélioration des performances et corrigez ces problèmes de requête courants afin de pouvoir récolter les fruits de l'optimisation des requêtes SQL Server.
