Optimisation des performances SQL

Avant-propos : Aujourd'hui, je vais vous présenter une problématique plus importante, l'optimisation des performances SQL.

Comment rendre les instructions SQL plus efficaces lors du fonctionnement de la base de données est une question très importante Ci-dessous, je résumerai pour vous les problèmes d'optimisation des performances.

Optimisation des performances SQL

1. L'instruction SELECT doit spécifier le nom du champ

SELECT * augmentera beaucoup de consommation inutile (cpu, io, mémoire, bande passante réseau) ; augmente la possibilité d'utiliser des index de couverture

Lorsque la structure de la table change, la pause précédente doit également être mise à jour ; Par conséquent, il est nécessaire d'ajouter directement le nom du champ après la sélection.

2. La valeur contenue dans IN dans l'instruction SQL ne doit pas être trop grande

MySQL a effectué les optimisations correspondantes pour IN, c'est-à-dire que toutes les constantes de IN sont stockées dans un tableau, et ce tableau est en ordre.

Mais si la valeur est grande, la consommation sera relativement importante. Pour les valeurs continues, n’utilisez pas in si vous pouvez utiliser between ; ou utilisez plutôt connection.

3. Distinguer entre dans et existe, pas dans et ne pas existe

select * from 表A 
where id in (select id from 表B)

est équivalent à

select * from 表A 
where exists(select * from 表B where 表B.id=表A.id)

La différence entre dans et existe est principalement causé par la conduite L'ordre change (c'est la clé des changements de performances). Si elle existe, alors la table externe est la table de conduite et est accessible en premier. Si elle est IN, alors la sous-requête est exécutée en premier.

Donc IN convient aux situations où la surface extérieure est grande mais la surface intérieure est petite ; EXISTS convient aux situations où la surface extérieure est petite mais la surface intérieure est grande.

4. Il n'est pas recommandé d'utiliser une requête floue de préfixe %

Par exemple, LIKE « %name » ou LIKE « %name% », ce type de requête entraînera un échec de l’analyse complète de la table. Mais LIKE "name%" peut être utilisé.

Éviter la conversion de type implicite :

La conversion de type se produit lorsque le type de champ de colonne dans la clause Where est incohérent avec le type du paramètre transmis. Il est recommandé pour déterminer le premier paramètre, tapez où

5. Pour l'index conjoint, la règle de préfixe la plus à gauche doit être suivie

Par exemple, l'index contient les champs identifiant, nom, école , Vous pouvez utiliser le champ id directement, ou dans l'ordre id, name, mais name ne peut pas utiliser cet index ;

Ainsi, lors de la création d'un index conjoint, vous devez faire attention à l'ordre des champs de requête couramment utilisés.

Pour résumer les suggestions ci-dessus :

1. Évitez les opérations de calcul sur les champs d'index

2. Évitez d'utiliser not a8093152e673feb7aba1828c43532094 !=

3. 🎜>

3. Évitez la conversion de type de données sur les champs d'index

4. Évitez d'utiliser des fonctions sur les champs d'index

5. Évitez d'utiliser des valeurs nulles dans les colonnes indexées

6. Règles de déclaration pour WHERE

7. Essayez d'éviter d'utiliser in, not in ou d'avoir la clause WHERE. Vous pouvez utiliser exist, not exist au lieu de in, not in

8. . Ne ​​déclarez pas de nombres au format caractère, ne déclarez pas de valeurs de caractères au format numérique, sinon l'index sera invalide

Voici quelques problèmes résumés pour tout le monde. Pour plus de questions, veuillez visiter les tutoriels correspondants. sur le site PHP chinois :

https://www.php.cn/course/list/51/type/2.html

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!