Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

5 syntaxes SQL et principes de requête pour une meilleure surveillance de la base de données

L'adoption d'une bonne syntaxe SQL et de bonnes pratiques d'écriture de requêtes améliorera l'efficacité de la surveillance de votre base de données et, par conséquent, améliorera les performances globales de votre base de données. Il existe plusieurs façons éprouvées d'améliorer les performances de la base de données grâce à des ajustements de syntaxe et de requête. Nous en avons choisi 5 sur lesquels nous concentrer.

1. CASE Expressions

Voici quelques bonnes pratiques pour obtenir les meilleures performances des expressions CASE :

  • Les expressions CASE améliorent les performances en déplaçant l'ancien code procédural dans du code déclaratif qui peut ensuite être optimisé. Pour les expressions CASE de base, utilisez , qui est le plus facilement optimisé. Pour les expressions CASE étendues, le hachage et d'autres techniques seront les plus utiles.
  • Étant donné que les clauses WHEN sont testées de gauche à droite, il est préférable d'organiser vos clauses de manière à ce que les plus probables soient répertoriées en premier. Cela réduira le temps consacré à la numérisation inutile.
  • La plupart des optimiseurs excluent également les tests redondants en tenant compte de l'ordre d'exécution. Dès qu'une clause WHEN s'exécute, il n'est pas nécessaire de tester à nouveau cette clause. Cependant, de nombreux optimiseurs ne sont pas bons pour lire les expressions CASE imbriquées, il est donc préférable de les aplatir à un seul niveau.

2. Double déduction et la clause de fenêtre

En SQL, "double dipping" signifie visiter la même table plus d'une fois, ce qui ralentit considérablement votre requête. Idéalement, essayez de faire tous vos travaux en une seule visite à la table. Mais si cela n'est pas possible, il existe plusieurs façons d'atténuer l'impact sur les performances.

L'utilisation de tables temporaires construites à partir de la même table de base réunies n'est vraiment pas la meilleure façon d'éviter les doubles déductions. Une meilleure solution consiste à utiliser l'optimiseur de votre moteur SQL pour afficher les vues et partager les résultats sous forme de table de travail.

Si vous êtes limité à un optimiseur moins que stellaire, utilisez des tables temporaires et faites le travail manuellement.

Bien que les méthodes ci-dessus soient parfaitement acceptables, la meilleure façon d'éviter les doubles déductions consiste à utiliser la clause window car les sous-clauses fonctionnent de la même manière que les fonctionnalités de sous-requête. Par exemple :

  • La clause PARTITION BY est comme un GROUP BY local qui divise la table en groupes.
  • La clause ORDER BY impose un ordre trié.
  • Le cadre de fenêtre (ROW ou RANGE) est comme une clause WHERE locale.

Vous pouvez optimiser les fonctions de la fenêtre en suivant ces règles :

  • Dans l'index, triez d'abord les colonnes de la clause PARTITION BY, puis les colonnes utilisées dans la clause ORDER BY.
  • Inclure toute autre colonne référencée dans la requête en tant que colonnes incluses de l'index.

3. Utiliser les procédures stockées

Les mappeurs relationnels objet (ORM) causent de nombreux problèmes de performances lorsqu'ils génèrent leur propre code. Si vous devez utiliser des ORM, écrivez vos propres procédures stockées afin que les performances n'en souffrent pas.

L'utilisation de procédures stockées améliore les performances de plusieurs manières, notamment :

  • Ils envoient moins de données sur le réseau, donc les transactions sont plus rapides
  • Ils permettent des appels plus courts
  • Les procédures stockées sont plus faciles à tracer dans les outils de profil
  • Étant donné qu'une procédure stockée est un objet réel dans votre base de données, il est plus facile d'obtenir des statistiques de performances, ce qui facilite la détection des problèmes de performances
  • La réutilisation du plan d'exécution augmente
  • Ils facilitent le traitement des cas extrêmes et ajoutent un comportement d'audit ou de verrouillage des modifications
  • Les procédures stockées ne sont pas vulnérables aux attaques par injections SQL

4. SUPPRIMER et METTRE À JOUR par lots

La suppression ou la mise à jour d'un grand nombre de données à partir d'un balayage de table volumineux utilise beaucoup de ressources car les deux instructions s'exécutent en une seule transaction. C'est un tueur de performances car si une erreur se produit pendant l'exécution de la transaction et que vous devez l'arrêter, le système doit annuler l'intégralité de la transaction. La restauration de grandes quantités de données prend beaucoup de temps et bloque d'autres transactions.

Vous pouvez éviter ce problème de performances en effectuant des mises à jour et des suppressions par petits lots. Lorsque vous exécutez ces transactions par lots, si la transaction est supprimée, la restauration est beaucoup plus petite. La restauration d'une petite quantité de données ne prend pas beaucoup de temps, et d'autres transactions peuvent fonctionner pendant que le lot est validé sur le disque.

5. Ne récupérez pas plus de colonnes que nécessaire

L'une des principales causes de requêtes peu performantes est la récupération de colonnes superflues. Évitez les pratiques qui entraînent généralement le renvoi d'un nombre excessif de colonnes. Gardez à l'esprit ce qui suit :

  • L'utilisation inutile de "SELECT *" dans une requête renverra probablement plus de colonnes que nécessaire. C'est un gaspillage de ressources et verrouille les ressources des autres utilisateurs. Il est particulièrement important de ne pas utiliser indifféremment "SELECT *" dans les bases de données SQL en colonnes.
  • Effectuer un copier-coller pour réutiliser le code peut générer des colonnes superflues.
  • Lorsque vous invoquez une VUE, vous pouvez vous retrouver avec des colonnes imbriquées. Désimbriquez les requêtes peu performantes pour vérifier quelles colonnes sont là et vous débarrasser des colonnes surdimensionnées dont vous n'avez pas besoin. Une bonne indication que vous avez un problème est que vous avez une clause WHERE avec des conditions supplémentaires et une clause FROM avec des jointures externes supplémentaires.

Ce ne sont là que quelques-unes des façons dont une approche consciencieuse de la syntaxe SQL et de l'écriture de requêtes peut améliorer la surveillance des bases de données. N'ayez pas peur d'en essayer d'autres. Une base de données performante est essentielle pour atteindre les objectifs commerciaux de chaque organisation.