Salut a tous
 
Je veux faire un :
 
ALTER TABLE ma_table ORDER BY champ1 DESC.
 
Sur une table de 100 000 enregistrements, la requete met plus de 8s pour s'effectuer
 
J'ai loupé kke chose ?
 
N'y a t il pas une autre requete pour classer des enregistrements a la maniere de ce ALTER ?
 
Merci a tous
 
PS : BDD MySQL 4.0.13

Faire un index ordonné ?
 
PS: je vois pas l'intérêt de trier physiquement les données, ça réduira pas spécialement les accès disques (un serveur correctement dimensionné dispose de suffisament de mémoire pour contenir l'intégrité des indexes en mémoire) et dès que tu vas rajouter/modifier des lignes du va polluer l'ordre, donc ça ne sert à rien.
 
Sinon, c'est normal, un alter est toujours lent, puisque tu touches aux données physiques, donc grossomodo, c'est comme si tu lançais un defrag sur une région du disque très fragmentée...

Rhooo le mec sous windows!
 
effectivement, le ALTER comme ça n'a aucune interet dans le sens ou tu peux obtenir le meme résultat avec un index. de plus, comme le dit MB, l'index peut tenir en RAM (on va dire que sa taille est souvent bine inférieure à celle de la table), et ça structure bien plus efficace en termes de recherche. l'autre plus, c'est que tu peux indexés plusieurs champs, là ou avec un alter tu mets une préférence sur un champ donné, au très grand détriment de tous les autres. et en plus c'est lent, ce qui est bien normal. tu sais ce qu'il te reste à faire

Beh mon idée, a la base c'était de faire un ORDER BY champ1 DESC dans une requete (Pour afficher des enregistrements)
 
Or il est peut etre preferable de trier ce champ, comme si MySQL triait les résultats par défaut ...
 
Du coup, dans ma requete d'affichage, j'aurai pu enlever le ORDER BY, vu k'il m'aurait de toute facon tout trier par champ1.
 
J'espere avoir été clair

 
Je comprends assez mal cette histoire d'index
 
Mon champ est deja indexé, mais quand je veux afficher les résultats du 99 500 au 99 530 par exemple, j'obtiens des temps proches de 0.5s
 
Ca se comprend vu que MySQL scanne une fois la table, puis la rescanne pour la trier

oui, mais ton alter ne va te servir que si tu fais une requete qui renvoie un nombre enorme d'entrée et que tu les veux dans l'odre. par ce que sur 100.000 entrées, si tu fais une requete qui renvoie 10 entrées, c'est pas la mort à trier. alors qu'avec alter, tu force le tri complet; et la c'est la mort... vraiment fait des index...

 
C'est pas la mort, mais pour les derniers enregistrements, c'est tout de meme de l'ordre de 0.5s.
 
Et vu que c'est le cadre de la conception d'un forum, c'est pas tip top

des ALTER là... c'est possible ça? 30 éléments à trier seulement   pas la peine de trier toute la table

 
Nan nan !
Je dois trier TOUTE la table, car n'importe quel enregistrement est suceptible d'etre sorti

c'est quoi ta requete?

l'index est là. encore une fois, tu prends le problème à l'envers. tu ne vas pas trier 100.000 éléments pour ensuite en choisir 30 et magique, ils sont déjà dans l'odre, ça ne vaut pas le coup, mais alors pas du tout.

C'est un truc tout con :
 
 

 
$debut et $nbpostspage peuvent etre changé (En fait, c'est pour la page des topics cette requete, donc quand tu changes de page, ces deux variables changent aussi )

 
Effectivement, mais j'essaye de trouver un solution pour avoir de bon temps de traitement a l'affichage

c'est bizarre... elle fait combien de Mo ta table? par ce que c'est simpliste comme requete, ça devrait pas être la mort...
 
et avoir ta requete, alter ne sert vraiment à rien

Ou alors, je peux laisser mon ORDER BY dernier_date DESC, et faire un CRON chaque nuit en faisant mon ALTER
 
Ca peut surement MySQL nop ?

non, c'est nul comme solution ça... et surtout ça sert à rien

La table fait 18 Mo

Merde je comprends plus la
 
J'viens de toucher a un truc, et je fais du 0.170s maintenant

fais un test un peu plus poussé s'il te plait: fait une série de 10/100 requetes avec des param différents pour etre sur

j'en étais sur. ben devait y avoir un truc en attente, un index à mettre à jour, ou une autre connerie

 
Ha nan j'ai rien dit

 
Cmt ca ?
Je change les valeurs du LIMIT ?

oui pour voir
et essaye d'en sortir de statistiques / nombre de résultat,  temps nécessaire par résultat

Oki

Euh... C'est koi ton serveur ? Un serveur mutualisé faisant tourner 200 BDD sur un P75 ?
 
Nan, parceque je m'étais amusé à faire un bench sur mon portable P100 (on peut pas imaginer plus lent, que ce soit le CPU, le disque, ou le fait qu'il n'y a que 32 Mo de RAM) qui tournais sous Linux.
Et j'obtenais de meilleurs résultat avec une table contenant 1 000 000 d'enregistrement, en faisant des fonctions de regroupement

Vire le WHERE, ça ira mieux

LIMIT 10 (10 derniers enregistrements sur 100 000) > Page générée en 0.888034 secondes
 
LIMIT 100 > Page générée en 0.8926029 secondes
 
 
LIMIT 1000 > Page générée en 0.9745231 secondes

 

 
Barton 2500+
1 Go DDR
DD 120 Go 7200 t/min
 
OUINNN, y a un truc qui cloche la !  

=> Fait un index qui porte sur trash et dernier_date, trié sur dernier_date
 
Enfin... Chais pas si MySQL supporte les index ordonnés

 
Le champ TRASH est indexé, mais je vais essayer kand meme

J'ai rien gagné en enlevant le WHERE

 
Deja indexé ces deux champ
 
Quant a l'index ordonné, je ne sais pas cmt faire

tu crois le système tri les résultats en fonction de l'index? ou alors tu veux dire qu'il les sélectionne dans l'odre?

C'est pas normal que ce soit si long

Je ne pense pas qu'il les selectionne dans l'ordre vu qu'il doit rescanner la table pour la trier

ben évidemment, ct un reponse alac
 
t'as pas une putain d'option: reconstruire la base de données?

 
Je sais bien !
 
Mais bon, le TRASH était deja indexé, donc a ce niveau la, ca roule

Bah, c'est un index avec une structure d'arbre binaire.
Donc pour retrouver des champs suivant un ordre c'est extrêment rapide, puisqu'une simple recherche dicotomique permet en très peu d'ittérations de retrouver les noeuds entiers contenant les lignes à retourner.

 
J'ai fais un REPAIR, ANALYSE, OPTIMIZE

Bah écoute, moi j'ai eu un problème similaire, j'ai viré le maximum de WHERE dans ma requête, et ça a grandement amélioré les choses, même si les champs étaient indexés