Quelques malentendus courants à propos de Mysq

Malentendus courants

1. count(1) et count(primary_key) valent mieux que count(*)

Afin de compter le nombre d'enregistrements, de nombreuses personnes utilisent count(1) et count(primary_key) au lieu de count(*). En fait, c'est un malentendu. Pour certains scénarios, cela peut entraîner une dégradation des performances, car la base de données a effectué des optimisations spéciales pour l'opération de comptage count(*).

1. count(column) et count(*) sont les mêmes

Ce malentendu même parmi de nombreux ingénieurs seniors Ou c'est courant parmi les administrateurs de base de données, et beaucoup de gens le tiennent pour acquis. En fait, count(column) et count(*) sont des opérations complètement différentes et ont des significations complètement différentes.

count(column) signifie combien d'enregistrements dans l'ensemble de résultats dont le champ de colonne n'est pas vide

count(*) signifie combien d'enregistrements il y a dans l'ensemble de résultats

1. Sélectionner a, b dans… permet à la base de données d'accéder à moins de données que sélectionner a, b, c dans…

Ce malentendu est Il existe principalement parmi un grand nombre de développeurs. La raison principale est qu'ils ne connaissent pas grand-chose aux principes de stockage de la base de données.

En fait, la plupart des bases de données relationnelles sont stockées en lignes, et les opérations d'accès aux données sont basées sur une unité d'E/S de taille fixe (appelée bloc ou page généralement 4 Ko, 8 Ko... La plupart du temps, multiple). les lignes sont stockées dans chaque unité IO, et chaque ligne stocke tous les champs de la ligne (à l'exception des types spéciaux de champs tels que lob).

Ainsi, que nous prenions un ou plusieurs champs, la quantité de données à laquelle la base de données doit accéder dans la table est en fait la même.

Bien sûr, il y a des exceptions, c'est-à-dire que notre requête peut être complétée dans l'index, c'est-à-dire que lorsque seulement deux champs a et b sont récupérés, il n'est pas nécessaire de renvoyer la table, et le champ c n'est pas dans l'index utilisé, il faut revenir à la table pour obtenir ses données. Dans ce cas, le volume IO entre les deux sera assez différent.

1. trier par doit nécessiter une opération de tri

On sait que les données de l'index sont effectivement ordonnées, si notre If les données requises sont dans le même ordre qu'un index et notre requête est exécutée via cet index, la base de données omettra généralement l'opération de tri et renverra les données directement, car la base de données sait que les données répondent déjà à nos besoins de tri.

En fait, utiliser des index pour optimiser SQL avec des exigences de tri est une méthode d'optimisation très importante

Lecture approfondie : Analyse de l'implémentation de MySQL ORDER BY, le principe de base de l'implémentation de GROUP BY dans MySQL et Le principe de base de mise en œuvre de MySQL DISTINCT a une analyse plus approfondie dans ces trois articles, en particulier le premier

1. S'il y a un tri de fichiers dans le plan d'exécution , le disque sera traité Tri des fichiers

Ce malentendu n'est pas de notre faute, mais est dû à la formulation utilisée par les développeurs MySQL. filesort est l'information que nous pouvons voir affichée dans la colonne « Extra » lorsque nous utilisons la commande expliquer pour afficher le plan d'exécution d'une instruction SQL.

En fait, chaque fois qu'une instruction SQL nécessite une opération de tri, "Using filesort" s'affichera, ce qui ne signifie pas qu'il y aura une opération de tri de fichiers.

Lecture approfondie : Comprendre le tri de fichiers dans la sortie de la commande MySQL Explain, j'ai une introduction plus détaillée ici

• Principes de base

1. Aussi peu de jointures que possible

L'avantage de MySQL est la simplicité, mais c'est en fait son inconvénient à certains égards. L'optimiseur MySQL est très efficace, mais en raison de sa quantité limitée d'informations statistiques, la possibilité d'écarts dans le processus de travail de l'optimiseur est plus grande. Pour Join multi-tables complexes, d'une part, en raison de son optimiseur limité, et d'autre part, des efforts insuffisants ont été déployés dans Join, de sorte que les performances sont encore loin derrière celles de leurs prédécesseurs de bases de données relationnelles telles qu'Oracle. Mais s’il s’agit d’une simple requête portant sur une seule table, cet écart sera très faible et même meilleur que celui de ces prédécesseurs de bases de données dans certains scénarios.

1. Triez le moins possible

Les opérations de tri consomment plus de ressources CPU, donc réduire le tri peut réduire les accès au cache Dans Dans des scénarios avec des capacités d'E/S suffisantes telles qu'un débit élevé, cela affectera grandement le temps de réponse de SQL.

Pour MySQL, il existe de nombreuses façons de réduire le tri, telles que :

• Optimiser en utilisant l'index pour trier comme mentionné dans le malentendu ci-dessus

• Réduire le nombre d'enregistrements participant au tri

• Ne triez pas les données sauf si nécessaire

• Évitez les opérations consommatrices de ressources. Les instructions SQL avec DISTINCT, UNION, MINUS, INTERSECT, ORDER BY démarreront l'exécution du moteur SQL, une ressource- la fonction de tri de consommation (SORT). DISTINCT nécessite une opération de tri, tandis que d'autres nécessitent au moins deux tris

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!