Quelles sont les techniques courantes pour la base de données MySQL ?

1. Comment choisir le type de serveur ?

La signification de chaque paramètre dans la fenêtre de configuration du serveur MySQL est la suivante.

Cette option permet de spécifier le type de configuration du serveur. Cliquez sur le bouton bas à droite de cette option pour voir 3 options.

Les significations spécifiques des trois options sont les suivantes :

Cette option représente un poste de travail de bureau personnel typique pour le développement. Supposons que plusieurs applications de bureau soient en cours d’exécution sur la machine. Configurez le serveur MySQL pour utiliser un minimum de ressources système.

Server Machine (serveur) : Cette option représente le serveur MySQL qui peut fonctionner avec d'autres applications, telles que les serveurs FTP, de messagerie et Web. Le serveur MySQL est configuré pour utiliser une proportion appropriée de ressources système.

DedicatedMySQL Server Machine (serveur MySQL dédié) : Cette option représente un serveur qui exécute uniquement le service MySQL. On suppose qu'aucune autre application n'est en cours d'exécution. Le serveur MySQL est configuré pour utiliser toutes les ressources système disponibles. En tant que débutant, il est recommandé de choisir l'option [Development Machine], qui consomme moins de ressources système.

2. Comment utiliser les caractères spéciaux dans MySQL ?

Symboles tels que guillemet simple ('), guillemet double ("), barre oblique inverse (), etc. Ces symboles ne peuvent pas être directement saisis et utilisés dans MySQL, sinon ils produiront des résultats inattendus. Dans MySQL, ces caractères spéciaux sont appelé Pour échapper des caractères, la saisie doit commencer par un symbole de barre oblique inverse (''), donc lorsque vous utilisez des guillemets simples et des guillemets doubles, vous devez respectivement saisir (') ou ("), et lorsque vous saisissez une barre oblique inverse, vous devez saisir ( ), Les autres caractères spéciaux incluent le retour chariot (), le saut de ligne (), la tabulation (ab), le retour arrière (), etc. Lors de l'insertion de ces caractères spéciaux dans la base de données, ils doivent être échappés.

3. Comment MySQL effectue-t-il une comparaison de chaînes sensible à la casse ?

MySQL n'est pas sensible à la casse sous la plate-forme Windows, donc la fonction de comparaison de chaînes n'est pas non plus sensible à la casse. Pour effectuer une comparaison sensible à la casse, utilisez le mot-clé BINARY avant la chaîne. Par exemple, par défaut, le résultat renvoyé de 'a'='A' est 1. Si le mot-clé BINARY est utilisé, le résultat de BINARY'a'='A' est 0. En cas de respect de la casse, 'a' et 'A' Ce n'est pas la même chose.

Compétences en optimisation des instructions MySQL

L'optimisation des performances de la base de données MySQL est le seul moyen de développer la base de données MySQL. L'optimisation des performances de la base de données MySQL est également un témoin des progrès de la base de données MySQL. Voici quelques conseils pour l'optimisation des instructions MySQL. :

1. Vous devriez essayer 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.

Afin d'optimiser les requêtes, les analyses de tables complètes doivent être évitées autant que possible. Ensuite, nous devrions donner la priorité à la création d’index sur les colonnes impliquées dans Where et Trier par.

3. Essayez d'éviter de juger la valeur nulle du champ 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

peut être sur 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 :

sélectionnez l'identifiant à partir de t où num=0

4 Essayez d'éviter d'utiliser ou. dans la clause Where pour connecter les conditions, sinon le moteur abandonnera. Utilisez un index pour effectuer une analyse complète de la table, par exemple :

sélectionnez l'identifiant à partir de t où num=10 ou num=20

Vous pouvez interroger comme ceci :

select id from t Where num=10

union all

select id from t Where num=20

5 La requête suivante entraînera également une analyse complète de la table : (ne peut pas précéder le signe de pourcentage)

select. id de t où nom comme '�c%'

Pour améliorer l'efficacité, vous pouvez considérer le texte intégral Récupérer.

6. In et not in doivent également être utilisés 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, n'utilisez pas between si vous le pouvez Utilisé dans :

sélectionnez l'identifiant à partir de t où num entre 1 et 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 ; Si le plan d'accès est construit au moment de la compilation et que la valeur d'une variable est inconnue, cette valeur 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 où num=@num

peut être modifié pour forcer la requête à utiliser un index :

select id from t with(index(index name )) 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 par le moteur de l'utilisation de l'index et une analyse complète de la table. Par exemple :

select id from t which num/2=100

doit être remplacé par :

select id from twhere num=100*2

9 Vous devez essayer d'éviter d'effectuer des opérations fonctionnelles sur les champs du fichier. clause Where. Cela entraînera l'abandon de l'utilisation de l'index par le moteur et une analyse complète de la table. Par exemple :

select id from twhere substring(name,1,3)='abc'--id dont le nom commence par abc

select id from twhere datediff(day,createdate,'2005-11-30′ )= 0–'2005-11-30′ l'identifiant généré

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

11. Lors de l'utilisation d'un champ d'index comme condition, si l'index est un index composite, alors le premier champ de l'index doit être utilisé comme condition pour garantir que le système utilise l'index, sinon l'index 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, 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 code ne renverra aucun ensemble de résultats. , mais cela consommera des ressources système. Il convient de remplacer ceci :

create table #t(...)

13 Dans de nombreux cas, il est judicieux d'utiliser exist au lieu de in :

select num from a. où num in (select num from b)

Remplacez par l'instruction suivante :

select num from awhere exist (sélectionnez 1 from b which num=a.num)

14. optimise les requêtes en fonction des données de la table Oui, 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. Par exemple, s'il y a un champ sexe dans une table, et presque. la moitié sont des hommes et l'autre moitié des femmes, 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, vous devez donc être prudent. lors de la construction de l’index. Considéré au cas par cas. Il est préférable de ne pas avoir plus de 6 index sur une table. S'il dépasse ce nombre, vous devez vous demander s'il est nécessaire de créer des index sur certaines colonnes rarement utilisées.

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, cela entraînera un ajustement de l'ordre des enregistrements. l'intégralité des enregistrements de la table, ce qui coûtera beaucoup de temps. Si le système d'application doit mettre à jour fréquemment les colonnes de données d'index clusterisé, vous devez déterminer si l'index doit être créé 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. Le moteur compare chaque caractère de la chaîne un par un lors du traitement des requêtes et des jointures, de sorte que les types numériques ne doivent être comparés qu'une seule fois au lieu d'un par un.

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 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. 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 créer une table pour éviter de provoquer un grand nombre de journaux et améliorer la vitesse si la quantité de données ne l'est pas ; grande, afin d'alléger les ressources de la table système, la table doit d'abord être créée puis insérée.

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 alors envisager de les réécrire.

26. Essayez d'éviter les opérations de transactions importantes et d'améliorer la simultanéité du 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!