à regarder mes différents spip, je m'aperçois que spip_index_dico.MYI fait
en général 50% de la taille de spip_index_dico.MYD ; question idiote :
est-ce vraiment utile d'avoir un index si celui-ci est presque aussi gros
que la table qu'il est censé accélérer ?
Par exemple, sur le diplo anglais (j'ai supprimé les tables < 1 ko), les
trois index signalés par une * paraissent disproportionnés ??
C'est justement ce que je test en ce moment... et il me semble qu'il n'y a pas d'interret puisque les délais de réponse d'une même requetes avec ou sans l'index sont négligeable.... Ou peut être je m'y prend mal... j'aimerais aussi avoir un eclaircicement sur le sujet
à regarder mes différents spip, je m'aperçois que spip_index_dico.MYI fait
en général 50% de la taille de spip_index_dico.MYD ; question idiote :
est-ce vraiment utile d'avoir un index si celui-ci est presque aussi gros
que la table qu'il est censé accélérer ?
Il faudrait faire l'étude sur un certain nombre de requêtes en
simultané.
Il n'y a pas que le temps de réponse de l'index ou de la base qui
compte.
En théorie, la BDD supporte un certain nombre de requêtes en simultané,
le code aussi, et ilfaut comparer.
Je crois qu'il y a des outils pour ça, cf. php.net...
à regarder mes différents spip, je m'aperçois que spip_index_dico.MYI fait
en général 50% de la taille de spip_index_dico.MYD ; question idiote :
est-ce vraiment utile d'avoir un index si celui-ci est presque aussi gros
que la table qu'il est censé accélérer ?
En fait :
- une recherche sur les données : O(n) (recherche exhaustive)
- une recherche sur un index : O(log(n)) (arbre équilibré)
C'est très bien expliqué dans la doc MySQL.
Au boulot, j'ai des tables dont les index sont plus gros que les données.
Mais si je supprimais les index, les consultations seraient mille fois plus
lentes.
le Wed, 20 Mar 2002 13:53:41 +0100
Antoine <antoine@rezo.net> écrivait :
- une recherche sur les données : O(n) (recherche exhaustive)
- une recherche sur un index : O(log(n)) (arbre équilibré)
Dans le meilleur des cas, c'est pire : si l'index est une clef
primaire, l'accés est en temps constant (O(1)) car c'est géré comme
une table de hashage.
Au fait ... je ne me souvient plus si quelqu'un avait répondu : vous
avez essayé le système d'index full-text de MySQL associé aux requètes
MATCH ?
Dans le meilleur des cas, c'est pire : si l'index est une clef
primaire, l'accés est en temps constant (O(1)) car c'est géré comme
une table de hashage.
Pas avec le type de tables par défaut sous MySQL.
Au fait ... je ne me souvient plus si quelqu'un avait répondu : vous
avez essayé le système d'index full-text de MySQL associé aux requètes
MATCH ?
Non, car c'est trop récent pour être compatible tous hébergeurs
(y a notamment un certain Valentin qui n'a pas remis MySQL à jour
depuis des années).
le Wed, 20 Mar 2002 16:41:27 +0100
Antoine <antoine@rezo.net> écrivait :
Arnaud Fontaine wrote:
> Dans le meilleur des cas, c'est pire : si l'index est une clef
> primaire, l'accés est en temps constant (O(1)) car c'est géré comme
> une table de hashage.
Pas avec le type de tables par défaut sous MySQL.
En pratique si ... C'est vrai qu'il faudrait utiliser le type de table
HEAP pour ça, mais les tests que j'ai lu ou fait indiquent tous la
même chose : la gestion du cache des tables pour le type MyISAM
construit des tables de hash en mémoire vive.
> Au fait ... je ne me souvient plus si quelqu'un avait répondu : vous
> avez essayé le système d'index full-text de MySQL associé aux requètes
> MATCH ?
Non, car c'est trop récent pour être compatible tous hébergeurs
(y a notamment un certain Valentin qui n'a pas remis MySQL à jour
depuis des années).
LOL
Ca m'étonne pas Il offre encore PHP/FI ??? :))
Blague à part, il n'y aurait pas moyen d'avoir 2 (voire plus ... htdig) systèmes
d'indexation, le choix se faisant à la config ?
le Wed, 20 Mar 2002 17:38:44 +0100
Antoine <antoine@rezo.net> écrivait :
Arnaud Fontaine wrote:
> En pratique si ... C'est vrai qu'il faudrait utiliser le type de
> table
> HEAP pour ça, mais les tests que j'ai lu ou fait indiquent tous la
> même chose : la gestion du cache des tables pour le type MyISAM
> construit des tables de hash en mémoire vive.
C'est bizarre. Comment ferait-il pour optimiser les inégalités,
order by, et autres "clé in (..,..)" avec des tables hash ?
D'après les comparatifs que j'ai pu faire entre une table HEAP qui est
une table de hash, et une MyISAM, sur les clef PRIMAIREs (ce que
j'indiquais dans mon premier mail), le cache des indexes primaires
d'une MyISAM est un dictionnaire. Pour les inégalités et les order by,
tu ordonnes en n(log(n)) les clefs .. pour les in (a,b,....), c'est un
accès direct pour chaque clef dans le (a,b,....)
Mais bon .. la seule conclusion c'est que les HEAP et les MyISAM ont
une gestion équivalente sur les index ... en fait .
