Maison  >  Article  >  base de données  >  Comment améliorer l'efficacité des requêtes SQL

Comment améliorer l'efficacité des requêtes SQL

一个新手
一个新手original
2017-10-18 10:13:211347parcourir

1. Pour optimiser la requête, vous devez essayer d'éviter les analyses de table complètes. Vous devez d'abord envisager de créer des index sur les colonnes impliquées dans Where et de les trier.

2. Essayez d'éviter de juger la valeur nulle des champs dans la clause Where, sinon le moteur abandonnera l'utilisation de l'index et effectuera une analyse complète de la table, telle que :
sélectionnez l'identifiant à partir de t où num est nul
Vous pouvez définir la valeur par défaut 0 sur num, vous assurer qu'il n'y a pas de valeur nulle dans la colonne num du tableau, puis interroger comme ceci :
sélectionner l'identifiant à partir de t où num = 0

3. Essayez d'éviter les clauses Where. Utilisez l'opérateur != ou <>, sinon le moteur abandonnera l'utilisation de l'index et effectuera une analyse complète de la table.

4. Essayez d'éviter d'utiliser ou dans la clause Where pour connecter les conditions, sinon le moteur abandonnera l'utilisation de l'index et effectuera une analyse complète de la table, telle que :
sélectionnez l'identifiant de t où num= 10 ou num =20
Vous pouvez interroger comme ceci :
sélectionnez l'identifiant à partir de t où num=10
union all
sélectionnez l'identifiant à partir de t où num=20

5.in et not in sont également requis À utiliser avec prudence, sinon cela entraînera une analyse complète de la table, telle que :
sélectionnez l'identifiant de t où num in(1,2,3)
Pour les valeurs continues, si vous le pouvez utiliser entre, ne pas utiliser dans :
sélectionnez l'identifiant à partir de t où num entre 1 et 3

6 La requête suivante entraînera également une analyse complète de la table :
sélectionnez l'identifiant à partir de t où nom. comme '%abc%'
Pour améliorer l'efficacité, envisagez la recherche en texte intégral.

7. si dans où L'utilisation de paramètres dans la clause entraînera également une analyse complète de la table. Étant donné que SQL résout les variables locales uniquement au moment de l'exécution, l'optimiseur ne peut pas différer la sélection d'un plan d'accès jusqu'au moment de l'exécution ; il doit effectuer la sélection au moment de la compilation ; Couru Cependant, si le plan d'accès est construit au moment de la compilation, la valeur de la variable est toujours inconnue et ne peut pas être utilisée comme entrée pour la sélection d'index. Par exemple, l'instruction suivante effectuera une analyse complète de la table :
select id from twhere num=@num
Vous pouvez la modifier pour forcer la requête à utiliser un index :
select id from t with( index(nom de l'index)) Where num= @num

8. Essayez d'éviter d'effectuer des opérations d'expression sur les champs de la clause Where, ce qui entraînerait l'abandon de l'utilisation de l'index par le moteur et une analyse complète de la table. Par exemple :
sélectionnez l'identifiant de t où num/2=100
doit être remplacé par :
sélectionnez l'identifiant de t où num=100*2

Essayez d'éviter les clauses Where. Les opérations de fonction sont effectuées sur les champs du champ, ce qui amènera le moteur à abandonner l'utilisation de l'index et à effectuer une analyse complète de la table. Par exemple :
sélectionnez l'identifiant à partir de t où substring(name,1,3)='abc'--id dont le nom commence par abc
sélectionnez l'identifiant à partir de t où datediff(day,createdate,'2005-11- 30 ')=0--'2005-11-30' L'identifiant généré
doit être modifié par :
sélectionnez l'identifiant à partir de t où le nom est comme 'abc%'
sélectionnez l'identifiant à partir de t où créé>= '2005 -11-30' et createate<'2005-12-1'

10. N'effectuez pas de fonctions, d'opérations arithmétiques ou d'autres opérations d'expression sur le côté gauche de "=" dans la clause Where, sinon le système peut ne pas être en mesure d'utiliser correctement les index.

11. Lors de l'utilisation d'un champ d'index comme condition, si l'index est un index composite, le premier champ de l'index doit être utilisé comme condition pour garantir que le système utilise l'index, sinon l'index le fera. not ne sera pas utilisé et l'ordre des champs doit être autant que possible cohérent avec l'ordre de l'index.

12. N'écrivez pas de requêtes dénuées de sens. Par exemple, si vous devez générer une structure de table vide :
sélectionnez col1,col2 dans #t à partir de t où 1=0
Ce type de le code ne retournera rien Le jeu de résultats, mais il consommera des ressources système, doit être modifié comme suit :
create table #t(...)

13 Dans de nombreux cas, using exist au lieu de. in est un bon choix :
sélectionnez num depuis a où num in(sélectionnez num depuis b)
Remplacez par l'instruction suivante :
sélectionnez num depuis a où existe (sélectionnez 1 depuis b où num=a. num)

14 .Tous les index ne sont pas efficaces pour les requêtes. SQL optimise les requêtes en fonction des données de la table Lorsqu'il y a une grande quantité de données en double dans la colonne d'index, la requête SQL peut ne pas utiliser le. index, comme une table avec les champs sexe, homme et femme Presque moitié-moitié, donc même si un index est construit sur le sexe, cela n'aura aucun effet sur l'efficacité des requêtes.

15. Plus il y a d'index, mieux c'est. Bien que les index puissent améliorer l'efficacité de la sélection correspondante, ils réduisent également l'efficacité de l'insertion et de la mise à jour, car l'insertion ou la mise à jour. mise à jour L'index peut devoir être reconstruit de temps en temps, donc la manière de créer l'index doit être soigneusement étudiée et dépend de la situation spécifique. Il est préférable de ne pas avoir plus de 6 index sur une table. S'il y en a trop, vous devez vous demander s'il existe des index construits sur certaines colonnes qui ne sont pas couramment utilisées. nécessaire.

16. Évitez autant que possible de mettre à jour les colonnes de données d'index clusterisées, car elles sont groupées. L'ordre des colonnes de données d'index est l'ordre de stockage physique des enregistrements de la table. Une fois la valeur de la colonne modifiée, l'ordre de l'ensemble des enregistrements de la table sera ajusté, ce qui consommera des ressources considérables. Si le système d'application nécessite des mises à jour fréquentes colonne de données d'index clusterisé, vous devez alors déterminer si l'index doit être construit en tant qu'index clusterisé.

17. Essayez d'utiliser des champs numériques. Si les champs contiennent uniquement des informations numériques, essayez de ne pas les concevoir comme des champs de caractères. Cela réduirait les performances des requêtes et des connexions et augmenterait la surcharge de stockage. En effet, le moteur comparera chaque caractère de la chaîne un par un lors du traitement des requêtes et des connexions, et une seule comparaison suffit pour les types numériques.

18. Utilisez autant que possible varchar/nvarchar au lieu de char/nchar, car tout d'abord, les champs de longueur variable ont un petit espace de stockage et peuvent économiser de l'espace de stockage. Deuxièmement, pour les requêtes, l'efficacité de la recherche est relativement grande. le petit champ est évidemment plus élevé.

19. N'utilisez select * from t nulle part, remplacez "*" par une liste de champs spécifique et ne renvoyez aucun champ inutilisé.

20. Essayez d'utiliser des variables de table au lieu de tables temporaires. Si la variable de table contient une grande quantité de données, sachez que les index sont très limités (uniquement les index de clé primaire).

21. Évitez de créer et de supprimer fréquemment des tables temporaires pour réduire la consommation des ressources des tables système.

22. Les tables temporaires ne sont pas inutilisables et leur utilisation appropriée peut rendre certaines routines plus efficaces, par exemple lorsque vous devez référencer à plusieurs reprises un certain ensemble de données dans une grande table ou une table couramment utilisée. Toutefois, pour des événements ponctuels, il est préférable d'utiliser une table d'export.

23. Lors de la création d'une table temporaire, si la quantité de données insérées en même temps est importante, vous pouvez utiliser select into au lieu de create table pour éviter d'augmenter la vitesse d'un grand nombre de journaux ; Les données ne sont pas volumineuses, afin de faciliter le système. Pour les ressources de table, vous devez d'abord créer la table puis l'insérer.

24. Si des tables temporaires sont utilisées, toutes les tables temporaires doivent être explicitement supprimées à la fin de la procédure stockée. Commencez par tronquer la table, puis supprimez-la. Cela peut éviter le verrouillage à long terme des tables système.

25. Essayez d'éviter d'utiliser des curseurs car les curseurs sont moins efficaces. Si les données exploitées par le curseur dépassent 10 000 lignes, vous devriez envisager de les réécrire.

26. Avant d'utiliser la méthode basée sur le curseur ou la méthode de table temporaire, vous devez d'abord rechercher une solution basée sur un ensemble pour résoudre le problème. La méthode basée sur un ensemble est généralement plus efficace.

27. Comme les tables temporaires, les curseurs ne sont pas inutilisables. Utilisez FAST_FORWARD pour les petits ensembles de données Les curseurs sont souvent supérieurs aux autres méthodes de traitement ligne par ligne, notamment lorsque plusieurs tables doivent être référencées pour obtenir les données requises. Les routines qui incluent des « totaux » dans un jeu de résultats sont généralement plus rapides que l'utilisation d'un curseur. Si pendant le développement Si le temps le permet, vous pouvez essayer à la fois la méthode basée sur le curseur et la méthode basée sur les ensembles pour voir quelle méthode fonctionne le mieux.

28. Définissez SET NOCOUNT ON au début de toutes les procédures stockées et déclencheurs, et définissez SET NOCOUNT OFF à la fin. Il n'est pas nécessaire d'envoyer un message DONE_IN_PROC au client après chaque instruction de procédures stockées et de déclencheurs.

29. Essayez d'éviter les opérations de transactions volumineuses et d'améliorer la simultanéité du système.

30. Essayez d'éviter de renvoyer de grandes quantités de données au client. Si la quantité de données est trop importante, vous devez vous demander si la demande correspondante est raisonnable

.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn