2010-07-17 2 views
0
rejoindre

avec EXPLAIN pour la requête ci-dessous montreaide index sur

SELECT cha.cid AS cid, 
     cha.data AS dl 
FROM cha, c_users 
WHERE uid = 808 
AND cha.cid = c_users.cid; 
  1. il effectue une analyse complète sur la table cha
  2. utilise l'index de plusieurs colonnes (cid, uid) de c_users.

Pourquoi n'utilise-t-il pas l'index de clé primaire de cha et effectue plutôt une analyse de table complète. Existe-t-il un meilleur moyen d'optimiser la requête/table.

Edit: cha.cid est ma clé primaire. Ajouté après le commentaire ci-dessous.

+0

Est-ce que 'cha.cid' est votre clé primaire? –

+0

ouais cha.cid est une clé primaire – rampr

+0

J'ai trouvé que la scinder en deux requêtes et en créant les index appropriés était mieux – rampr

Répondre

1

Dans une BTREE normale, et un index sur (cid, uid), une analyse sera nécessaire si vous ne cherchez pas spécifier cid et uniquement pour uid. Un index sur (uid, cid) (notez l'ordre) serait/pourrait aider. Ce n'est en aucun cas une garantie qu'il sera utilisé, MySQL peut deviner qu'une analyse complète pourrait être plus rapide (lecture continue) si un certain index/jointure nécessitera probablement un certain pourcentage important de l'index à utiliser , et d'autres raisons. Vous pouvez vérifier avec FORCE INDEX si l'utilisation de la clé par rapport à une analyse est en fait plus rapide ou non (désactiver le cache de requête sur un serveur de test avant de le tester).

+0

Rien à voir avec être BTREE - les index de couverture doivent correspondre aux colonnes les plus à gauche dans l'ordre défini. Si le premier ne correspond pas, l'index ne sera pas pris en compte. –

+0

Mon mauvais, était le confondre avec l'astuce standard index spatial 2 entier (RTREE), ce qui bien sûr n'a rien à voir avec le problème à la main, était juste un brainfart personnel, et exigent toujours deux entier d'avoir une sorte de limites . Pour ma défense: il était très tard ici;) – Wrikken

-1

... Ne serait-

SELECT cha.cid AS cid, 
     cha.data AS dl 
    FROM cha INNER JOIN c_users ON cha.cid = c_users.cid 
    WHERE uid = 808; 

plus idiomatiques?

(sous la direction de prendre en compte sur le commentaire de Knittl).

+1

la syntaxe est 'FROM table1 INNER JOIN table2 ON ...', pas avec une virgule – knittl

+0

Merci, knittl. Je vais modifier la réponse comme vous le suggérez. –

0

Créer un index pour la colonne uid.

Lorsque vous posez la question sur la performance, la production de EXPLIQUER et les instructions CREATE TABLE rend les choses beaucoup plus facile pour les aides. Merci de les ajouter la prochaine fois.

+0

J'ai décrit la sortie d'EXPLAIN. Aurez-vous besoin de plus d'informations? – rampr

0

Depuis cha n'a pas un covering index disponible pour cette requête, il doit accéder aux pages de données de toute façon pour récupérer certaines des données dont il a besoin. En se basant sur les statistiques de la table, l'optimiseur a décidé que le moment de la première scrutation de l'index, puis du saut dans les pages de données, est pire que de simplement balayer la table.