Scénarios d’usage du Magasin des requêtes - Azure Database pour PostgreSQL - Serveur flexible
S’APPLIQUE À : 
Azure Database pour PostgreSQL - Serveur flexible
Vous pouvez utiliser le Magasin des requêtes dans de nombreux scénarios dans lesquels il est essentiel de suivre et de gérer les performances des charges de travail prévisibles. Penchez-vous sur les exemples suivants :
- Identification et ajustement des requêtes les plus coûteuses.
- Tests A/B.
- Maintien de performances stables pendant les mises à niveau.
- Identification et amélioration des charges de travail ad hoc.
Identifier et ajuster les requêtes coûteuses
Identifier les requêtes les plus longues à s’exécuter
Utilisez des vues du Magasin des requêtes sur la base de données azure_sys de votre serveur pour identifier rapidement les requêtes les plus longues. En général, ces requêtes ont tendance à consommer le plus de ressources. L’optimisation de vos requêtes les plus longues à s’exécuter peut améliorer les performances en libérant des ressources utilisées par d’autres requêtes exécutées sur votre système.
Cibler les requêtes avec des différences de performances
Le Magasin des requêtes découpe les données de performances en fenêtres de temps pour vous permettre de suivre les performances d’une requête au fil du temps. Vous pouvez ainsi identifier exactement quelles requêtes contribuent à une augmentation du temps total passé. Par conséquent, vous pouvez effectuer un dépannage ciblé de votre charge de travail.
Gérer les requêtes coûteuses
Quand vous identifiez une requête dont les performances ne sont pas optimales, l’action à entreprendre dépend de la nature du problème. Voici des exemples possibles de ces actions :
- Vérifiez que les statistiques sont à jour pour les tables sous-jacentes utilisées par la requête.
- Envisagez de réécrire les requêtes coûteuses. Par exemple, tirez parti du paramétrage des requêtes et réduisez l’utilisation du code SQL dynamique. Implémentez une logique optimale lors de la lecture des données comme l’application de filtrage de données du côté base de données, plutôt que du côté de l’application.
Test A/B
Utilisez le Magasin des requêtes pour comparer les performances des charges de travail avant et après un changement d’application que vous prévoyez d’introduire, ou avant et après une migration. Exemples de scénarios d’utilisation du Magasin des requêtes pour évaluer l’impact de changements sur les performances des charges de travail :
- Migration vers des versions majeures de PostgreSQL.
- Déploiement d’une nouvelle version d’une application.
- Modification de la quantité de ressources accordées au serveur.
- Modification de l’un des paramètres du serveur qui affectent son comportement.
- Création d’index manquants sur des tables référencées par des requêtes coûteuses.
- Migration d’un serveur unique Azure Database pour PostgreSQL vers un serveur flexible Azure Database pour PostgreSQL.
Dans n’importe lequel de ces scénarios, appliquez le workflow suivant :
- Exécutez votre charge de travail avec le Magasin des requêtes avant le changement planifié pour générer une base de référence des performances.
- Appliquez les modifications souhaitées à un moment contrôlé dans le temps.
- Continuez à exécuter la charge de travail suffisamment longtemps pour générer l’image des performances du système après le changement.
- Comparez les résultats avant et après le changement.
- Déterminez s’il faut conserver le changement ou revenir en arrière.
Identifier et améliorer les charges de travail improvisées
Certaines charges de travail n’ont pas de requêtes dominantes que vous pouvez ajuster pour améliorer les performances globales de l’application. Ces charges de travail se caractérisent généralement par un nombre relativement important de requêtes uniques, chacune d’elles consommant une partie des ressources système. Chaque requête unique est rarement exécutée, donc sa consommation individuelle du runtime n’est pas critique. En revanche, étant donné que l’application génère en permanence de nouvelles requêtes, une partie significative des ressources système est consacrée à la compilation des requêtes, ce qui n’est pas optimal. En général, cette situation se produit si votre application génère des requêtes (au lieu d’utiliser des procédures stockées ou des requêtes paramétrables), ou si elle s’appuie sur des frameworks de mappage de relationnel objet qui génèrent des requêtes par défaut.
Si vous contrôlez le code d’application, vous pouvez envisager de récrire la couche d’accès aux données pour utiliser des procédures stockées ou des requêtes paramétrables. Cependant, cette situation peut également être améliorée sans changements de l’application en forçant le paramétrage des requêtes pour la totalité de la base de données (toutes les requêtes) ou pour les modèles de requête individuels ayant le même hachage de requête.