À quoi devez-vous faire attention lors de l’optimisation des requêtes pour le Big Data dans MySQL ?

Remarques sur l'optimisation des requêtes Big Data dans MySQL : 1. Lors de l'optimisation des requêtes, les analyses de table complètes doivent être évitées autant que possible. 2. Les jugements de valeur nuls sur les champs de la clause Where doivent être évités ; et Not in doivent également être utilisés avec prudence ; 4. Essayez d'éviter d'utiliser la clause or dans la connexion ; 5. Essayez d'éviter d'utiliser des curseurs.

Méthodes d'optimisation des requêtes Big Data dans MySQL :

1 Lors de l'optimisation des requêtes, essayez d'éviter les requêtes complètes. Pour les analyses de table, vous devez d'abord envisager de créer des index sur les colonnes impliquées dans Where et Trier par.

2. 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, par exemple : sélectionnez l'identifiant à partir de t où num est nul. be on num Définissez la valeur par défaut 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 != ou a8093152e673feb7aba1828c43532094 opérateurs dans la clause Where, sinon le moteur abandonnera. Effectuez une analyse complète de la table à l'aide d'un index.

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 à partir de t où num=10 ou num =20. Une requête comme celle-ci :

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ée avec prudence, sinon elle 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, vous pouvez utiliser between au lieu de in :

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 : sélectionnez l'identifiant à partir de t où le nom ressemble à '%李%' To. 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 créé au moment de la compilation, les valeurs des variables sont toujours inconnues et ne peuvent donc pas être utilisées 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 where num=@num Vous pouvez la modifier 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, ce qui amènera le moteur à abandonner son utilisation 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. Essayez d'éviter d'effectuer des opérations de fonction sur les champs de la clause Where, ce qui entraînerait l'abandon de l'utilisation de l'index par le moteur et l'exécution d'une analyse complète. analyse de table. Par exemple : sélectionnez id from t où substring(name,1,3)='abc', l'identifiant dont le nom commence par abc doit être remplacé par :

select id from t where name like ‘abc%’

10. "=" dans la clause Where Effectue des fonctions, des opérations arithmétiques ou d'autres opérations d'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. 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é. Cela devient comme ceci :

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)

Remplacer. avec l'instruction suivante :

select num from a where exists(select 1 from b where num=a.num)

14. Tous les index ne sont pas valides 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. ne peut pas utiliser l'index. Par exemple, il y a un champ sexe dans une table. Les hommes et les femmes sont presque la moitié chacun, 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 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. Vous devez éviter 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 la table entière. les dossiers seront ajustés. Cela consomme des ressources considérables. Si le système d'application doit mettre à jour fréquemment les colonnes de données d'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 varchar/nvarchar au lieu de char/nchar autant que possible, 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. petit champ É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 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.

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 afin d'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 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, d'abord truncate table, puis drop table, pour é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. 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 et SET NOCOUNT OFF à la fin de toutes les procédures stockées et déclencheurs. Pas besoin d'envoyer des DONE_IN_PROC messages au client après avoir exécuté 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 les exigences correspondantes sont raisonnables.

Plus de recommandations d'apprentissage gratuites connexes : tutoriel MySQL(vidéo)

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!