Concernant les problèmes d'efficacité des requêtes d'index Mysql

Question

SELECT COUNT(*) FROM `set_gif` WHERE `zhuanid` = 0 AND `webid` IN ('0','2','21','22','27','11','31') AND `empty` = 0 LIMIT 1 [ RunTime:0.1423s ]
SELECT `id`,`webid`,`catid`,`path`,`pname`,`pathall`,`title`,`cdn`,`sort`,`likecount`,`fsize`,`time`,`viewcount`,`likecount` FROM `set_gif` WHERE `zhuanid` = 0 AND `webid` IN ('0','2','21','22','27','11','31') AND `empty` = 0 ORDER BY time desc,id desc LIMIT 0,10 [ RunTime:0.0045s ]

Deux instructions SQL, ce dernier runtime signifie temps d'exécution, le volume de données est de 150W

Description du champ zhuanid est une valeur numérique, webid est une valeur numérique, vide est 0 ou 1

L'index commun utilisé par SQL dans la première phrase est un ensemble d'index pour zhuanid webid vide.
L'index utilisé par SQL dans la deuxième phrase est un ensemble d'index par zhuanid webid vide.

Pourquoi le décompte dans la première phrase prend-il si longtemps ? Par rapport à la requête complexe dans la deuxième phrase, cela prend très peu de temps

Answer 1

La première phrase est sql, limite 1
La deuxième phrase est sql, limite 0, 10
Vous avez demandé à count de compter 1,5 million d'éléments.... Voulez-vous être plus rapide que de vérifier les 10 premiers éléments ?

Answer 2

Je suppose : le champ d'index n'est pas défini pour être non nullable, ce qui empêche count(*) d'utiliser l'index.

De plus, ces deux déclarations elles-mêmes ne sont pas équivalentes. La première s'applique à l'ensemble du tableau, mais la seconde ne semble pas avoir de comparaison

.

Answer 3

Vous devez examiner votre plan d'exécution. Si le premier jeu de résultats SQL est volumineux, vous devez analyser tous les enregistrements qui remplissent les conditions. Dans ce cas, le deuxième SQL utilise l'index d'identification temporelle et n'a besoin que de rechercher. 10 enregistrements qui remplissent les conditions. C'est tout, donc ce sera plus rapide. De plus, l'index combiné de zhuanid webid vide n'utilisera que la colonne zhuanid et la partie plage de webid. Vous pouvez modifier l'ordre d'index pour zhuanid webid vide

.

Answer 4

Une fois le premier SQL exécuté, le résultat est enregistré dans le cache.

L'exécution du deuxième SQL repose sur le Cache du premier SQL, elle sera donc plus rapide (en fait, le deuxième SQL utilise le tri, il devrait donc être plus lent).

L'affiche peut l'exécuter après l'exécution du premier SQL

RESET QUERY CACHE;

Réinitialisez le cache puis exécutez le deuxième SQL, le résultat est différent.