Comment améliorer la vitesse de requête de la base de données pour des millions d'éléments

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 Trier par.

2. Essayez d'éviter les jugements de valeur nuls 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, comme : 　

select id from t where num is null

peut être utilisé dans num Définissez la valeur par défaut 0 sur la table, assurez-vous qu'il n'y a pas de valeur nulle dans la colonne num de la table, puis interrogez comme ceci : 　

select id from t where num=0

3. Essayez d'éviter d'utiliser les opérateurs != ou <> dans la clause Where, 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 : 　

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 not in doivent également être utilisés avec prudence, sinon cela entraînera une analyse complète du tableau, tel que : 　

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

Pour les valeurs continues, si vous pouvez utiliser entre , ne pas utiliser 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%'

Pour améliorer l'efficacité, vous pouvez envisager une recherche en texte intégral.

7. Si des paramètres sont utilisés dans la clause Where, cela 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 ; 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 : 8. Essayez d'éviter d'effectuer des opérations d'expression sur les champs de la clause Where, car le moteur abandonnerait l'utilisation de l'index et effectuerait une analyse complète de la table. Par exemple :

select id from t where num=@num

doit être remplacé par :

select id from t with(index(索引名)) where num=@num

9. Essayez d'éviter d'effectuer des opérations de fonction sur les champs de la clause Where, car le moteur abandonnerait l'utilisation de l'index et effectuerait une analyse complète de la table. Tels que : 　

　select id from t where num/2=100

Doit être remplacé par :

select id from t where num=100*2

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 pourrait ne pas être en mesure d'utiliser l'index correctement.

select id from t where substring(name,1,3)='abc'--name以abc开头的id
　　select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id

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 : 　

select id from t where name like 'abc%'
　　select id from t where createdate>=&#39;2005-11-30&#39; and createdate<&#39;2005-12-1&#39;

. Ce type de code ne renverra aucun jeu de résultats, mais consommera des ressources système. Il doit être modifié comme suit :

. 13. Souvent, c'est un bon choix d'utiliser existe plutôt que dans : 　

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

Remplacer par ce qui suit :

　create table #t(...)

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 l'index, comme une table avec des champs. sexe, homme, femme est 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.

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

16. Vous devez éviter autant que possible de mettre à jour les colonnes de données d'index clusterisé, car l'ordre des colonnes de données d'index clusterisé 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 doit mettre à jour fréquemment les colonnes de données de l'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 premièrement, l'espace de stockage des champs de longueur variable est petit, ce qui peut économiser de l'espace de stockage. Deuxièmement, pour les requêtes, l'efficacité de la recherche dans un champ relativement petit 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 ensemble de données dans une table volumineuse 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 de provoquer un grand nombre de journaux et améliorer la vitesse si la quantité de données n'est pas importante ; , afin d'alléger les ressources de la table système, vous devez d'abord créer une 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, d'abord tronquer la table, puis supprimer la table. Cela peut éviter un verrouillage de longue durée 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. 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 des « totaux » dans un jeu 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.

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 les capacités de concurrence 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 les exigences correspondantes sont raisonnables.

[Recommandations associées]

1. Tutoriel vidéo gratuit MySQL

2. 5 erreurs courantes de conception de bases de données

3. Comment faire en sorte que Mysql ajoute des instructions SQL de contenu à la fin tout en conservant le contenu existant

4 Un résumé des méthodes d'écriture d'instructions SQL courantes dans MySQL

Explication détaillée de la façon d'utiliser MySQL pour générer des nombres aléatoires et connecter des chaînes

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!