Maison >base de données >SQL >Quelles sont les méthodes couramment utilisées pour l'optimisation SQL ?

Quelles sont les méthodes couramment utilisées pour l'optimisation SQL ?

青灯夜游
青灯夜游original
2020-08-24 13:12:388302parcourir

Les méthodes couramment utilisées pour l'optimisation SQL incluent : 1. Essayez d'éviter les analyses de table complètes et envisagez de créer des index sur les colonnes impliquées dans Where et Order By ; clause which.Jugement;3. Utiliser in et not in avec prudence;4.Essayer d'éviter les opérations de transactions volumineuses et d'améliorer la concurrence du système.

Quelles sont les méthodes couramment utilisées pour l'optimisation SQL ?

1. Pourquoi devrions-nous optimiser SQL

Au début de notre projet de développement, en raison des données commerciales, la quantité de SQL est relativement faible et l'impact de l'efficacité d'exécution de certains SQL sur l'efficacité de l'exécution du programme n'est pas évident, et le personnel de développement, d'exploitation et de maintenance ne peut pas juger dans quelle mesure SQL affecte l'exécution l'efficacité du programme. Par conséquent, une optimisation spéciale de SQL est rarement effectuée. À mesure que le temps s'accumule et que la quantité de données commerciales augmente, l'impact de l'efficacité de l'exécution de SQL sur l'efficacité de l'exécution du programme augmente progressivement. pour optimiser SQL.

2. Quelques méthodes courantes d'optimisation SQL

1 Lors de l'optimisation des requêtes, essayez d'éviter les analyses de table complètes. Commencez par déterminer où et par ordre. sur la colonne.

2. Essayez d'éviter les jugements de valeur nulle sur les champs de la clause Where, sinon le moteur abandonnera l'utilisation de l'index et effectuera une analyse complète de la table, telle que :

select id from t where num is null

peut être défini. sur num La valeur par défaut est 0. Assurez-vous qu'il n'y a pas de valeur nulle dans la colonne num du tableau, puis interrogez comme ceci :

select id from t where num=0

3 Essayez d'éviter d'utiliser les opérateurs != ou a8093152e673feb7aba1828c43532094 dans la clause Where, sinon le moteur sera abandonné 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 :

select id from t where num=10 or num=20

peut être interrogé. comme ceci :

select id from t where num=10    
union all    
select id from t where num=20

5.in et non in doit également être utilisé avec prudence, sinon cela entraînera une analyse complète de la table, telle que :

select id from t where num in(1,2,3)

Pour les valeurs continues, si vous pouvez utiliser entre, ne les utilisez pas dans :

select id from t where num between 1 and 3

6 La requête suivante entraînera également une analyse complète de la table :

select id from t where name like '%abc%'

7. pour éviter les opérations d'expression sur les champs de la clause Where, ce qui obligerait le moteur à abandonner l'utilisation de l'index et à effectuer une analyse complète de la table. Par exemple :

select id from t where num/2=100

doit être remplacé par :

select id from t where num=100*2

8 Essayez d'éviter d'effectuer des opérations fonctionnelles sur les champs de la clause Where, ce qui entraînerait un renvoi du moteur. en utilisant l'index et effectuez une analyse complète de la table. Par exemple :

select id from t where substring(name,1,3)='abc'--name以abc开头的id

doit être remplacé par :

select id from t where name like 'abc%'

9. 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 risque de ne pas utiliser correctement les index.

10. 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.

11. N'écrivez pas de requêtes dénuées de sens. Par exemple, si vous devez générer une structure de table vide :

select col1,col2 into #t from t where 1=0

Ce type de code ne renverra aucun jeu de résultats, mais il consommera le système. ressources et doit être modifié comme ceci :

create table #t(...)

12 Souvent, c'est un bon choix d'utiliser exist au lieu de in :

select num from a where num in(select num from b)

Remplacer par l'instruction suivante :

select num from a where exists(select 1 from b where num=a.num)
<.>13. Pas tous les index Ceci est valable pour toutes 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 l'index. , s'il y a un champ sexe dans une table, près de la moitié est masculine et l'autre moitié féminine. Même si un index est construit sur le sexe, cela n'affectera pas l'efficacité des requêtes.

14. Plus il y a d'index, mieux c'est. Bien que l'index puisse améliorer l'efficacité de la sélection correspondante, il réduit également l'efficacité de l'insertion et de la mise à jour

Car il est possible d'insérer ou. mise à jour. L'index sera reconstruit, donc la manière de construire 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 est nécessaire de créer des index sur certaines colonnes qui ne sont pas couramment utilisées.

15. Essayez d'utiliser des champs numériques. Si les champs contenant uniquement des informations numériques ne doivent pas être conçus comme des champs de caractères, cela réduira les performances des requêtes et des connexions et augmentera 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 pour les types numériques, une seule comparaison suffit.

16. Utilisez autant que possible varchar au lieu de char, 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, de manière relative. petit champ L'efficacité de la recherche est évidemment plus élevée.

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

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

19. 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 une grande table ou un certain ensemble de données dans une table couramment utilisée. Toutefois, pour des événements ponctuels, il est préférable d'utiliser une table d'export.

20. 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 créer une table pour éviter de provoquer un grand nombre de journaux,

pour améliorer la vitesse ; si la quantité de données n'est pas grande. Afin d'alléger les ressources de la table système, vous devez d'abord créer la table, puis l'insérer.

21. Si des tables temporaires sont utilisées, toutes les tables temporaires doivent être explicitement supprimées à la fin de la procédure stockée, d'abord tronquer la table, puis supprimer la table, afin d'éviter le verrouillage à long terme des tables système.

22. 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.

23. 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.

24. Comme les tables temporaires, les curseurs ne sont pas inutilisables. L'utilisation de curseurs FAST_FORWARD avec de petits ensembles de données est souvent meilleure que d'autres méthodes de traitement ligne par ligne, en particulier lorsque plusieurs tables doivent être référencées pour obtenir les données requises.

Les routines qui incluent un « total » dans l'ensemble de résultats sont généralement plus rapides que l'utilisation d'un curseur. Si le temps de développement 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.

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

26. 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 les exigences correspondantes sont raisonnables.

Recommandations associées : "Tutoriel PHP", "Tutoriel mysql"

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