Maison  >  Article  >  base de données  >  Résumé des méthodes de requête d'instruction SQL d'optimisation MySQL couramment utilisées

Résumé des méthodes de requête d'instruction SQL d'optimisation MySQL couramment utilisées

伊谢尔伦
伊谢尔伦original
2017-07-17 15:41:011555parcourir

1. Pour optimiser la requête, essayez d'éviter les analyses de table complètes. Tout d'abord, pensez à créer des index sur les colonnes impliquées dans Where et à trier par.

2. Essayez d'éviter d'utiliser les opérateurs != ou a8093152e673feb7aba1828c43532094 dans la clause Where, sinon le moteur abandonnera l'utilisation de l'index et effectuera une analyse complète de la table.

3. Essayez d'éviter de porter des 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

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 :

select id from t where num=0


4 . Essayez d'éviter d'utiliser ou dans les conditions de connexion, 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. Ce qui suit La requête entraînera également une analyse complète de la table :

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

Pour améliorer l'efficacité, envisagez la récupération du texte intégral.

6.in et non in doivent également être utilisés avec prudence, sinon cela entraînera une analyse complète du tableau, comme :

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

Pour les valeurs continues, si vous peut être utilisé entre, ne pas utiliser dans Now :

select id from t where num between 1 and 3

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 :
select id from t which num=@num
peut être modifié pour forcer la requête à utiliser un index :

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

8. Essayez d'éviter les opérations d'expression sur les champs de la clause Where qui obligeraient 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

9. Vous devez essayer d'éviter d'effectuer des opérations fonctionnelles sur les champs de la clause Where, ce qui. entraînera l'abandon du moteur en utilisant les index et effectuera une analyse complète de la table. Par exemple :

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

doit être remplacé par :

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;

10. N'effectuez pas de fonctions, d'opérations arithmétiques ou d'autres opérations sur le côté gauche de ". =" dans la clause Where Évaluation de l'expression, sinon le système risque de ne pas utiliser l'index correctement.

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, comme 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 consommera le système. Les ressources doivent être modifiées comme suit :

create table #t(...)

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

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

Utilisez ce qui suit. déclaration Remplacer :

select num from a where exists(select 1 from b where 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. colonne d'index, SQL La requête ne peut pas utiliser l'index. Par exemple, s'il y a un champ sexe dans une table et que près de la moitié sont des hommes et l'autre moitié des femmes, même si un index est construit sur le sexe, cela n'affectera pas la requête. efficacité.

15. 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 l'index peut être reconstruit lors de l'insertion ou de la mise à jour, et alors. ? L'indexation nécessite un examen attentif et dépendra des circonstances. 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.

16. Évitez autant que possible de mettre à jour les colonnes de données d'index cluster, car l'ordre des colonnes de données d'index cluster 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 modifié. être ajusté. Cela consomme 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. Utilisez autant que possible 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é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 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.

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