Table des matières
Quand on fait des multiples requêtes Dans un système complexe, nous ne prenons souvent pas le chemin approprié pour avoir des performances optimales au niveau de la base de données, avec l'avancée technologique actuelle et la puissance de calcul que nous voyons souvent dans nos serveurs, nous pouvons penser que l'optimisation de la base de données appartient au passé.Cela ne pourrait pas être plus éloigné de la vérité, malgré l'avancement de la puissance de l'équipement, les bases de données sont fondamentales pour la performance des applications, pour cette raison une requête bien écrite et hautement optimisée peut signifier plusieurs secondes de charge qu'elle économise en le système, si nous multiplions cela par le nombre d'utilisateurs simultanés, nous voyons comment le coût et la puissance ont été gaspillés.
Optimiser les requêtes
La meilleure façon d'améliorer les performances de nos bases de données est de commencer par des requêtes bien écrites, plusieurs fois nous constatons que les requêtes ne sont pas bien écrites car elles ne sont pas aussi optimisées qu'elles devraient l'être, il y a plusieurs causes à cela, l'une d'entre elles est la réutilisation sans connaissance du code; Nous entendons par là que si à un moment donné nous avons fait une requête qui fonctionne pour nous avec un joint gauche Nous continuerons à l'appliquer lors de l'augmentation du nombre de tableaux à consulter, lors de sa modification et de la modification de certaines clauses par jointure interne Cela pourrait raccourcir le chemin et économiser la consommation du processeur.
SQL est un langage qui bien qu'il soit assez facile à lire, il a de nombreux aspects et de nombreuses variantes qui nous permettent de faire quelque chose qui fonctionne de la meilleure et la pire des manières, c'est à nous de savoir identifier si notre solution appartient à une catégorie ou autre.
Afin de savoir que nous sommes sur la bonne voie, l'une des choses les plus importantes est d'être mis à jour, c'est-à-dire que nous ne pouvons pas continuer à coder en SQL dans PostgreSQL comme si c'était la première version quand on est dans le version 9.
À propos de l'utilisation des sous-requêtes
C'est l'une des erreurs les plus courantes que nous commettons, et c'est que nous considérons une requête comme un ensemble de pièces que nous maillons ensemble jusqu'à ce que nous obtenions un résultat final, mais ce comportement a un impact important sur les performances de notre base de données.
Voyons un exemple de ce comportement typique :
SELECT tract_id, (SELECT COUNT (*) FROM recensement.facts As F WHERE F.tract_id = T.tract_id) As num_facts, (SELECT COUNT (*) FROM recensement.lu_fact_types As Y WHERE Y.fact_type_id IN (SELECT fact_type_id FROM recensement. faits F O F.tract_id = T.tract_id)) As num_fact_types FROM recensement.lu_tracts As T;
Maintenant, si nous voyons le graphique de la EXPLIQUE À partir de cette requête, nous réaliserons à quel point il est coûteux de le faire de cette manière :
AGRANDIR
SELECT T.tract_id, COUNT (f.fact_type_id) As num_facts, COUNT (DISTINCT fact_type_id) As num_fact_types FROM recensement.lu_tracts As T GAUCHE REJOINDRE recensement.facts As F ON T.tract_id = F.tract_id GROUP BY T.tract_id;
Dans cette nouvelle version de notre requête, nous évitons d'utiliser des sous-requêtes, nous faisons plutôt un équivalent avec joint gauche Oui par groupeSi nous voyons le graphique, nous pouvons faire la différence.
AGRANDIR
