10 optimisations d'instructions SQL peu connues

1. Certaines pratiques SQL courantes

(1) Les requêtes conditionnelles négatives ne peuvent pas utiliser d'index

select * from order where status!=0 and stauts!=1

ne pas/ne pas exister n'est pas une bonne habitude

Recommander "tutoriel vidéo mysql"

peut être optimisé dans la requête :

select * from order where status in(2,3)

(2) La requête floue principale ne peut pas utiliser l'index

select * from order where desc like '%XX'

au lieu de la requête floue principale :

select * from order where desc like 'XX%'

( 3) Il n'est pas approprié d'utiliser des index pour des champs avec peu de différenciation des données

select * from user where sex=1

Raison : Il n'y a que des genres masculins et féminins, et très peu de données sont filtrées à chaque fois, il n'est donc pas approprié d'utiliser des index.

En règle générale, les index peuvent être utilisés lorsque 80 % des données peuvent être filtrées. Pour le statut de la commande, s'il y a peu de valeurs de statut, il n'est pas approprié d'utiliser un index. S'il existe de nombreuses valeurs de statut et qu'une grande quantité de données peut être filtrée, un index doit être établi.

(4) Le calcul sur les attributs ne peut pas atteindre l'index

select * from order where YEAR(date) < = &#39;2017&#39;

Même si un index est établi à date, le tableau complet sera scanné, qui peut être optimisé pour le calcul de la valeur :

select * from order where date < = CURDATE()

Ou :

select * from order where date < = &#39;2017-01-01&#39;

2. Pratiques SQL pas si connues

(5) Si la majeure partie de l'activité est une seule requête, le les performances de l'utilisation de l'index Hash sont meilleures, comme le centre utilisateur

select * from user where uid=?
select * from user where login_name=?

Raison :

La complexité temporelle de l'index B-Tree est O(log(n))

Le la complexité temporelle de l'index de hachage est O(1)

(6) Les colonnes qui peuvent être nulles présentent des pièges potentiels dans les requêtes

Les index à colonne unique ne stockent pas de valeurs nulles, contrairement aux index composites. ne stocke pas toutes les valeurs nulles. Si une colonne peut être nulle, vous pouvez obtenir un ensemble de résultats ""Inattendu"

select * from user where name != 'shenjian'

Si le nom peut être nul, l'index ne stocke pas les valeurs nulles, et ces enregistrements. ne sera pas inclus dans le jeu de résultats.

Alors, veuillez utiliser des contraintes non nulles et des valeurs par défaut.

(7) Le préfixe le plus à gauche de l'index composite n'est pas la valeur. L'ordre Where de l'instruction SQL doit être cohérent avec l'index composite

Le centre utilisateur a établi un index composite de. (login_name, passwd)

select * from user where login_name=? and passwd=?
select * from user where passwd=? and login_name=?

peut atteindre l'index

select * from user where login_name=?

peut également atteindre l'index, qui satisfait au préfixe le plus à gauche de l'index composite

select * from user where passwd=?

ne peut pas atteindre le. index, et ne satisfait pas le préfixe le plus à gauche de l'index composite

( 8) Utilisez ENUM au lieu de la chaîne

ENUM enregistre TINYINT N'incluez pas de chaînes comme "Chine", "Pékin". et "Département de technologie" dans l'énumération. L'espace des chaînes est grand et l'efficacité est faible.

3. Niche mais pratiques SQL utiles

(9) S'il est clair qu'un seul résultat sera renvoyé, la limite 1 peut améliorer l'efficacité

select * from user where login_name=?

Peut être optimisé pour :

select * from user where login_name=? limit 1

Raison :

Vous savez qu'il n'y a qu'un seul résultat, mais la base de données ne le sait pas clairement et laissez-la arrêter activement le mouvement du curseur.

(10) Placer les calculs dans la couche de gestion au lieu de la couche de base de données permet non seulement d'économiser le processeur de données, mais a également des effets inattendus d'optimisation du cache de requêtes

select * from order where date < = CURDATE()

Ce n'est pas une bonne pratique SQL et devrait être optimisé comme :

$curDate = date('Y-m-d');
$res = mysql_query(
    &#39;select * from order where date < = $curDate&#39;);

Raison :

libère le CPU de la base de données

est appelé plusieurs fois et le SQL entrant est le même, afin que le cache de requêtes puisse être utilisé

(11) La conversion de type forcée entraînera le balayage de la table entière

select * from user where phone=13800001234

Pensez-vous qu'elle atteindra l'index du téléphone ? C'est une grosse erreur. Comment puis-je modifier cette déclaration ?

Enfin, encore une chose, n'utilisez pas select *, renvoyez uniquement les colonnes requises, ce qui peut grandement économiser la quantité de transmission de données et l'utilisation de la mémoire de la base de données.

Cet article provient du site Web php chinois, colonne tutoriel mysql, bienvenue pour apprendre !

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!