Quelles techniques peuvent être appliquées efficacement pour améliorer les performances des requêtes SQL? Y a-t-il des règles générales qui s'appliquent?Quelles techniques génériques peuvent être appliquées pour optimiser les requêtes SQL?
Je pense que l'utilisation de l'analyseur de requête SQL serait un bon début.
Dans Oracle, vous pouvez consulter le explain plan pour comparer les variations de votre requête
Assurez-vous que vous avez les index droit sur la table. Si vous utilisez fréquemment une colonne pour commander ou limiter votre jeu de données, un index peut faire une grande différence. J'ai vu dans un article récent que sélectionner distinct peut vraiment ralentir une requête, surtout si vous n'avez pas d'index.
L'optimisation évidente pour les requêtes SELECT est de s'assurer que vous avez des index sur les colonnes utilisées pour les jointures ou dans les clauses WHERE. Comme l'ajout d'index peut ralentir les écritures de données, vous devez surveiller les performances pour vous assurer de ne pas supprimer les performances d'écriture de la base de données, mais l'utilisation d'un bon outil d'analyse de requêtes peut vous aider à équilibrer les données.
La plus grande chose que vous pouvez faire est de rechercher des scans de table dans l'analyseur de requête SQL Server (assurez-vous d'activer "show plan d'exécution"). Sinon, il y a une myriade d'articles sur MSDN et ailleurs qui donneront de bons conseils. En aparté, quand j'ai commencé à apprendre à optimiser les requêtes, j'ai couru le profileur de requêtes sql server sur une trace, regardé le SQL généré, et essayé de comprendre pourquoi c'était une amélioration. Le profileur de requêtes est loin d'être optimal, mais c'est un bon début.
savoir ce qui se passe vraiment sous le capot - vous devriez être en mesure de comprendre les concepts suivants en détail:
Vous pouvez examiner quelques éléments pour optimiser les performances de vos requêtes.
Assurez-vous de disposer du minimum de données. Assurez-vous de sélectionner uniquement les colonnes dont vous avez besoin. Réduisez la taille des champs au minimum.
dénormaliser Envisager la base de données pour réduire les jointures
éviter les boucles (à savoir chercher les curseurs), bâton pour régler les opérations.
Implémentez la requête en tant que procédure stockée car elle est précompilée et s'exécutera plus rapidement.
Assurez-vous que les index sont corrects. Si votre base de données est principalement utilisée pour la recherche, pensez à plus d'index.
Utilisez le plan d'exécution pour voir comment le traitement est effectué. Ce que vous voulez éviter est un scan de table car c'est coûteux.
Assurez-vous que les statistiques automatiques sont activées. SQL a besoin de cela pour aider à décider de l'exécution optimale. Voir le super article de Mike Gunderloy pour plus d'informations. Basics of Statistics in SQL Server 2005
Assurez-vous que vos index ne sont pas fragmentés. Reducing SQL Server Index Fragmentation
Utiliser un avec statment pour gérer le filtrage de requête. Limiter chaque sous-requête au nombre minimal de lignes possible. puis rejoignez les sous-requêtes.
WITH
master AS
(
SELECT SSN, FIRST_NAME, LAST_NAME
FROM MASTER_SSN
WHERE STATE = 'PA' AND
GENDER = 'M'
),
taxReturns AS
(
SELECT SSN, RETURN_ID, GROSS_PAY
FROM MASTER_RETURNS
WHERE YEAR < 2003 AND
YEAR > 2000
)
SELECT *
FROM master,
taxReturns
WHERE master.ssn = taxReturns.ssn
A l'intérieur d'un sous-requêtes avec déclaration peut finir comme étant le même que des vues à roues alignées, ou générés automatiquement des tables temporaires. Je trouve dans le travail que je fais, les données de détail, qu'environ 70-80% du temps, il y a un avantage de performance.
100% du temps, il y a un avantage de maintenance.
D'autres points (mines sont basées sur un serveur SQL, puisque chaque backend db a ses propres implémentations qu'ils peuvent ou ne peuvent pas être vrai pour toutes les bases de données):
Évitez les sous-requêtes corrélées dans la partie sélection d'une instruction, ce sont essentiellement des curseurs.
Concevez vos tables pour utiliser les types de données corrects afin d'éviter d'avoir à leur appliquer des fonctions pour extraire les données. Il est beaucoup plus difficile de faire des calculs de date lorsque vous stockez vos données en tant que varchar par exemple.
Si vous constatez que vous effectuez fréquemment des jointures comportant des fonctions, vous devez penser à redéfinir vos tables.Si vos conditions WHERE ou JOIN incluent des instructions OR (qui sont plus lentes), vous pouvez obtenir une meilleure vitesse en utilisant une instruction UNION. UNION ALL est plus rapide que UNION si (et seulement si) les deux statements sont mutuellement exclusifs et retournent les mêmes résultats dans les deux sens.
EXISTE PAS est généralement plus rapide que NOT IN ou en utilisant une jointure gauche avec une clause WHERE d'ID = null
Dans une requête UPDATE ajouter une condition WHERE pour vous assurer que vous ne modifiez pas les valeurs qui sont déjà égales. La différence entre mettre à jour 10 000 000 enregistrements et 4 peut être assez importante!
Envisagez de pré-calculer certaines valeurs si vous les interrogez fréquemment ou pour les rapports volumineux. La somme des valeurs d'une commande ne doit être effectuée que lorsque la commande est effectuée ou ajustée, plutôt que lorsque vous récapitulez les résultats de 10 000 000 millions de commandes dans un rapport. Les pré-calculs doivent être effectués dans les déclencheurs afin qu'ils soient toujours à jour, c'est-à-dire les changements de données sous-jacents. Et il ne faut pas que ce soit juste des chiffres, nous avons un champ calculé qui concatène les noms que nous utilisons dans les rapports. Méfiez-vous des UDF scalaires, elles peuvent être plus lentes que de mettre le code en ligne.
La table temporaire a tendance à être plus rapide pour les grands ensembles de données et les variables de table plus rapidement pour les petites. En outre, vous pouvez indexer les tables temporaires.
La mise en forme est généralement plus rapide dans l'interface utilisateur que dans SQL.
Ne renvoyez pas plus de données que nécessaire.
Celui-ci semble évident, mais vous ne croiriez pas combien de fois je finis par corriger cela. Ne joignez pas aux tables que vous n'utilisez pas pour filtrer les enregistrements ou en appelant réellement l'un des champs dans la partie select de l'instruction. Les jointures inutiles peuvent être très coûteuses.
C'est une très mauvaise idée de créer des vues qui appellent d'autres vues qui appellent d'autres vues. Vous pouvez constater que vous vous joignez à la même table 6 fois quand vous n'avez besoin qu'une fois et que vous créez 100 000,00 enregistrements dans une vue sous-jacente afin d'obtenir les 6 qui sont dans votre résultat final. Lors de la conception d'une base de données, pensez à ne pas signaler uniquement l'interface utilisateur pour entrer des données. Les données sont inutiles si elles ne sont pas utilisées, alors réfléchissez à la façon dont elles seront utilisées après leur inclusion dans la base de données et à la manière dont elles seront conservées ou auditées. Cela va souvent changer la conception. (C'est une mauvaise raison de laisser un ORM concevoir vos tables, il ne pense qu'à un cas d'utilisation des données.) Les requêtes les plus complexes affectant le plus de données sont dans les rapports, donc la conception de modifications pour aider les rapports peut accélérer les requêtes (et les simplifier) considérablement.
Les implémentations de fonctionnalités spécifiques aux bases de données peuvent être plus rapides que l'utilisation de SQL standard (c'est l'une des façons de vendre leur produit), découvrez vos fonctionnalités de base de données et découvrez celles qui sont les plus rapides.
Et parce que cela ne peut pas être dit trop souvent, utilisez les index correctement, pas trop ou trop peu. Et faites vos clauses WHERE sargable (Capable d'utiliser des index).
+1, c'est mieux que la réponse acceptée – iruvar