Optimisation des performances MySQL pour rendre la base de données plus rapide

Dans le travail d'optimisation de la base de données, rendre les données aussi petites que possible afin que la table occupe moins d'espace sur le disque dur Garder l'espace aussi petit que possible est l'une des méthodes les plus couramment utilisées et les plus efficaces. Étant donné que les données sont réduites, la vitesse de lecture et d'écriture du disque dur peut être relativement améliorée et le traitement du contenu de la petite table pendant le processus de requête consomme moins de ressources système. De la même manière, si un index est défini sur une colonne plus petite, l’index occupera moins de ressources. Alors, comment les administrateurs de bases de données peuvent-ils perdre du poids pour leurs propres données ? L'auteur propose les suggestions suivantes à ce sujet :

Suggestion 1 : Les valeurs nulles ne prennent pas nécessairement de la place

Ici, je vais d'abord vous donner un peu d'alphabétisation. Certains administrateurs de bases de données pensent que les valeurs nulles n'occuperont pas les ressources système. En fait, c'est une mauvaise compréhension. Lors de la conception de la base de données, ils n'aiment pas définir les propriétés du champ sur NOT NULL. Laissez les utilisateurs saisir des données en fonction de leurs besoins. L'auteur estime que cette approche est préjudiciable aux performances de la base de données

L'opinion de l'auteur est que si possible, essayez de définir la colonne sur NOT NULL, c'est-à-dire qu'aucune valeur nulle n'est autorisée. Cela peut accélérer le traitement ultérieur et en même temps économiser un bit par colonne du point de vue du stockage des données, atteignant ainsi l'objectif de perte de poids des données. Dans le travail réel, s'il existe des situations dans lesquelles les utilisateurs ne sont pas tenus de saisir des données, les champs par défaut peuvent également être utilisés pour atteindre des objectifs non vides. Par exemple, dans le système de paie, les années de travail de l'utilisateur peuvent être définies par défaut sur 0 au lieu d'être vides. Bien sûr, si vous avez vraiment besoin de NULL, il n’y a aucun moyen. Mais en tant qu'ingénieur de bases de données, vous devriez essayer d'éviter d'utiliser des valeurs NULL.

Suggestion 2 : Utilisez un type de données aussi petit que possible

La taille du type de données affectera également la taille de la table sous-jacente. Par exemple, les deux types de données MEDIUMINT et INT peuvent être utilisés pour enregistrer des données entières, mais la précision qu'ils peuvent enregistrer est différente. Mais du point de vue du stockage des données, le premier nécessite environ 25 % d’espace de stockage en moins que le second. Pour cette raison, n'utilisez pas INT si MEDIUMINT peut être utilisé.

De plus, lors de la définition de la longueur des données, celle-ci doit être la plus courte possible tout en répondant aux besoins. Par exemple, il existe un champ pour le codage des employés dans le système d'évaluation des salaires. Si le code employé de l'entreprise a été déterminé, il est composé de cinq caractères. Ensuite lors de la définition du champ, il vous suffit de définir la longueur de 5 caractères. Cela peut non seulement réduire l'espace de stockage, mais également jouer une certaine fonction de relecture des données. Lorsque la longueur du code saisie par l'utilisateur dépasse 5 chiffres, les données ne peuvent pas être enregistrées.

Bien qu'il existe de nombreux types de données parmi lesquels choisir lors de la sauvegarde de certaines données, vous pouvez également définir un nombre relativement important de caractères. Cependant, choisir le type de données le plus petit possible peut contribuer à réduire l'espace de stockage des données et à atteindre l'objectif de perte de poids des données. Améliorant ainsi encore les performances de la base de données.

Suggestion 3 : La relation entre l'index et la taille de la table de données

L'auteur a mentionné au début de l'article que si un index est défini pour une colonne relativement petite, l'index occupera également moins de ressources. On peut voir que l'index et la taille du tableau de données sont également étroitement liés. Définir le bon index au bon endroit et au bon moment peut également atteindre l’objectif de perte de poids des données.

Comme d'habitude, chaque table de données peut avoir plusieurs index, mais il n'y a souvent qu'un seul index principal. Pour cette raison, l’index principal de chaque tableau doit être aussi court et concis que possible. Cela peut aider la base de données à l'identifier plus rapidement.

Un autre exemple consiste à indexer le préfixe autant que possible. Par exemple, si vous avez maintenant une table, vous devez définir un index sur une certaine colonne. Et cette colonne a une caractéristique, c'est-à-dire qu'elle a un préfixe unique sur les premiers caractères. Si tel est le cas, il serait préférable d’indexer étroitement ce préfixe plutôt que tous. Dans la base de données MySQL, il est pris en charge pour créer un index sur la partie la plus à gauche d'une colonne de caractères. Cela signifie que la base de données divisera un champ en deux parties selon certaines règles. Si les données de la partie avant peuvent rester uniques après le fractionnement, il vous suffit alors de définir un index sur la partie avant, et il n'est pas nécessaire de définir un index sur les données dans l'ensemble du champ. Cela peut sans aucun doute réduire les ressources occupées par l'indice et atteindre l'objectif de perte de poids. Les index plus courts offrent des vitesses de requête plus rapides. Parce qu'ils occupent moins d'espace sur le disque dur et qu'ils économiseront plus d'accès dans le cache d'index. Cela réduit le nombre de recherches sur le disque dur et améliore l'efficacité des requêtes.

La dernière chose à noter est que les index ne peuvent pas être abusés. L'utilisation d'index peut en effet améliorer les capacités de traitement des données, mais les index entraînent également une surcharge supplémentaire. Ce n'est que lorsque les avantages sont supérieurs à la surcharge que l'utilisation d'index peut améliorer les performances de la base de données. Sinon, cela aura l’effet inverse. Par exemple, si une table doit être stockée rapidement, si trop d'index sont définis sur la table, les index auront des effets secondaires. À cet égard, l'auteur suggère que si une table est accessible principalement via une combinaison de colonnes de recherche, il est préférable de ne définir qu'un seul index pour celles-ci. Bien entendu, cette partie index devrait être la colonne la plus couramment utilisée dans le travail quotidien. En dernier recours, si vous devez utiliser plusieurs index, il est préférable d'utiliser des colonnes avec plus de copies pour obtenir une meilleure compression d'index. Cela réduit la consommation accrue de ressources provoquée par l’utilisation de plusieurs index.

Suggestion 4 : Je ne peux toujours pas économiser sur les zones qui doivent être « pleines »

Une femme devrait être mince là où elle devrait être mince et être ronde là où elle devrait être rondelette. En fait, il en va de même pour les bases de données. Partout où vous pouvez économiser de l’espace sur le disque dur, enregistrez-le. Et ce qui ne peut pas être économisé ne peut pas être rationalisé pour perdre du poids. Parfois, cela peut se retourner contre vous.

L'auteur prend Varchar comme exemple. Comme dans MyISAM, si vous n'avez pas de colonnes de longueur variable, il est préférable d'utiliser des types de données de taille fixe. Bien que des types de données de longueur fixe soient utilisés, une certaine quantité d'espace de stockage est souvent gaspillée. Car si les données saisies par l'utilisateur sont insuffisantes et qu'une longueur fixe est utilisée, les données seront quand même stockées à cette longueur fixe. Mais dans ce cas, si vous pouvez utiliser une longueur fixe, vous devez quand même utiliser une longueur fixe. Car dans ce cas, même si une certaine quantité d'espace disque dur sera gaspillée, cela peut améliorer la vitesse d'interrogation des données.

On constate que la perte de poids des données ne peut en aucun cas améliorer les performances de la base de données. C'est comme économiser de l'argent pour augmenter les revenus, et cette économie doit être réalisée à la pointe de la technologie. Sinon, non seulement vous ne pourrez pas économiser d’argent, mais vous vous tirerez également une balle dans le pied. En termes simples, cela signifie être plus mince là où vous devriez être mince et être dodu là où vous devriez l'être. Rappelez-vous simplement cette phrase.

Suggestion 5 : Divisez la table pour atteindre des objectifs de perte de poids

Lorsque les fourmis déplacent de la nourriture, si un morceau de nourriture est trop gros pour être déplacé, les fourmis peuvent diviser le morceau de nourriture jusqu'à ce qu'il puisse être déplacé. C'est le principe du partage du gâteau. En fait, ce phénomène est souvent courant dans le travail quotidien. Par exemple, si nous avons une table de base de données, si elle contient de nombreux enregistrements, la vitesse autorisée de la table sera très lente. Dans ce cas, le tableau peut être divisé en plusieurs classeurs en fonction de certaines règles. Par exemple, il existe désormais une copie des informations de présence des employés de l'entreprise. Lors de l'interrogation, du tri et du comptage de cette table, le temps d'attente est très long. À ce stade, vous pouvez le diviser en différents classeurs selon les départements, puis y effectuer une analyse de données pertinente. Bien que la charge de travail soit plus importante à ce moment-là, la vitesse de traitement sera beaucoup plus rapide

Selon ce principe, lors de l'optimisation de la base de données, une grande table souvent numérisée peut être divisée en 2 ou plus. La représentation est très utile. Par exemple, dans mon travail quotidien, j'ai maintenant une table de données au format dynamique, et lorsque ces données utilisent une table d'analyse, je l'utiliserai pour trouver les lignes pertinentes dans une table au format statique relativement petite.

Grâce au fractionnement de ce tableau, un grand gâteau peut être divisé en plusieurs gâteaux plus petits pour faciliter les statistiques et l'analyse ultérieures des données. Bien entendu, la qualité de cet effet est directement liée aux règles de ce partage. Concernant la façon de diviser la table pour obtenir l’effet souhaité, c’est un autre sujet relativement important. En raison de l'espace limité ici, l'auteur ne donnera pas trop d'explications. Peut-être que dans des articles ultérieurs, l’auteur développera cette proposition et vous donnera une explication détaillée.

Ce qui précède est le contenu de l'optimisation des performances de MySQL pour rendre la base de données plus rapide. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !