Re: [résolu] critère IN, SELECT FIELD et performances
Simon Camerlo <scamerlo.work <at> gmail.com>
2009-03-02 04:34:31 GMT
Désolé de ne pas avoir pu répondre plus tôt, *beaucoup* de boulot...
Stephane a écrit :
> Simon Camerlo a écrit :
>> - parfois, quand la liste de paramètres du IN est trop longue, les
>> index ne sont pas utilisés *si l'index qu'on vise n'est pas la clé
>> primaire*, merci l'optimiseur de mysql
> bizarre ca, tu pourrais faire passer une de ces requete et la
> structure de ta table ?
SELECT id_rubrique
FROM `mabase`.spip_rubriques
WHERE id_parent IN
('-1','730','721','720','787','722','1141','743','751','779','798','732','727','846','910','726','728','716','723','724','714','725','960','979','718','729','767','695','696','693','697','715','731','713','717')
=> en fait je modifie ma remarque : cette requête a un comportement
erratique si un index sur id_parent seul est présent, elle se comporte
un peu mieux avec un index couplé sur (id_parent, id_rubrique) alors que
normalement ça n'a aucun impact sur le tri. Ce n'est donc visiblement
pas lié au fait que la clé soit primaire ou non, mais toujours au fait
que l'index soit "complet" (voir ci-dessous)
De plus elle utilisait l'index id_parent seul jusqu'à un certain nombre
de valeurs dans le IN (24 sur mon serveur de test, 26 sur le serveur
d'exploitation)...
>> (ça arrive souvent sur id_parent dans spip_rubriques, le nombre de
>> paramètres limite change d'un serveur à l'autre et d'une requête à
>> l'autre...). Néanmoins, c'est beaucoup mieux qu'avec FIELD seul qui,
>> lui, n'utilise jamais les index
>>
>> - idem quand on fait un select * : les index ne sont parfois pris en
>> compte que si toutes les colonnes renvoyées sont correctement
>> indexées :|
>> par exemple :
>> SELECT * FROM spip_mots_rubriques WHERE id_mot IN 1,2,3;
>> n'utilisera pas un index sur id_mot seul, il faut indexer
>> impérativement sur le couple (id_mot, id_rubrique)
> ben celle la, elle risque pas de marcher...
oui, désolé c'était juste un raccourci pour expliquer le principe car je
n'ai plus la requête en question sous la main.
> fait passer les requetes effectivement générées.
> La dans ce cas, il y a jointure sur spoip_mots_rubriques et c'est
> cette clause de jointure qui necessite l'indexation de la clé double
> (qui devrait normalement déclarée en primary et la deuxieme clé en index)
Pour le coup, je parlais bien d'une requête simple sur la table
spip_mots_rubriques, sans jointure donc.
J'ai fait des tests pour savoir pourquoi mes jointures n'utilisaient pas
d'index, et je me suis rendu compte de ce fait en tentant la requête
simple ci-dessus.
Autre exemple :
SELECT * FROM `mabase`.spip_auteurs
WHERE id_auteur NOT IN (2419)
AND statut!='5poubelle'
AND statut!='6forum'
AND statut!='nouveau'
ORDER BY statut, nom;
Celle-là, impossible de lui faire prendre un index sur cette table, j'en
ai créé un sur (statut, nom(30), id_auteur), rien à faire...
Je n'ai pas réussi à reproduire ça aujourd'hui, mais j'ai eu des cas la
semaine dernière où le simple fait de changer le SELECT * en SELECT
a,b,c (où a,b,et c sont les valeurs indexées) entraînait soudainement
l'utilisation de l'index en question.
>> - Question accessoire : impossible de surcharger critere_IN_dist par
>> critere_IN dans mes_fonctions.php (placé dans mon home/squelettes).
>> J'ai tout essayé, relancé apache et tout, mais il ne prend jamais
>> le code en compte (oui, j'ai vidé tmp, désactivé le couteau suisse,
>> etc.).
> ca c'est vraiment pas normal, ce critère n'est pas appelé d'une facon
> differente des autres.
> Ca voudrait dire que ton mes_fonctions n'est pas chargé au moment de
> la compilation...
Mon mes_fonctions.php est apparemment chargé puisque les fonctions
custom que j'utilise dans les squelettes passent sans problème.
Apparemment c'est juste la surcharge qui pose problème.
> quelle version exacte de Spip ? est-ce du mutualisé ?
spip 1.9.2g sur serveur dédié
> j'ai eu il y a un moment un pb dans les chemin, c'etait une vieille
> version du couteau suisse qui cassait les chemin avec la mutualisation
> (mais il y a longtemps que ca ne le fait plus)
Mon couteau suisse est en 1.7.20.03 révision 24011
Le problème persiste quand je le désactive et quand je vide /tmp (je
l'ai eu aussi sur d'autres fonctions, comme celle qui permet de changer
la taille de spip.log que j'ai dû forker aussi, par exemple)
> si tu veux comprendre, regarde dans public/composer la fonction
> public_composer_dist commence par inclure mes_fonctions si il existe
> avant de lancer la mécanique, est-ce que tu as bien le bon repertoire
> squelette à ce niveau ?
à priori oui...
>>
>> Dans tous les cas, merci à vous pour l'aide apportée, ça m'aurait
>> pris BEAUCOUP plus de temps pour m'en sortir tout seul.
>> Si ce retour peut aider à améliorer les perfs d'une future distrib,
>> alors tant mieux ;)
> ben ca c'est fait, mais des gens voulant profiter de ces optimisation
> en restant en 1.9.2, il y en aura sans doute d'autres donc c'est
> jamais du temps perdu.
En effet (j'avais lu un peu vite les messages précédents).
Merci et à bientôt.
Simon Camerlo
RSS Feed