Reprise du message précédent :

ca prend des ressources parce que y a enormement de donnee c'est tout
et des que tu fais des ET, tu degustes parce que t'es oublie de chopper tous les resultats avant d'appliquer les jointures.
Pour le Key Cache, les blocks sont gardes en memoire en fonction de leur utilisation (que tu peux rafiner avec MySQL >= 4.1).
Ils sont charger au fur et a mesure des besoins, sauf si tu fais explicitement un PRELOAD de l'index auquel cas il est stocke entierement en RAM.
 
 

L'index permet justement de lui assurer que l'ORDER BY va etre dans le bon ordre (a condition de faire l'ORDER BY sur le bon index quoi), donc il n'aura justement pas a tout scanner.

non, la il va faire du file sorting, parce que ca lui prenait bcp trop de temps de prendre tous les ids dans l'ordre via l'index file pour ensuite trouver leur correspondance dans le data file. Dans ce cas c'est bcp plus efficace de faire un full scan du fichier de data (donc acces sequentiel au niveau disque) pour ensuite faire le sorting en memoire, plutot que de faire un 2 seeks disque minimum (1 pour l'index et 1 pour la data correspondante) pour chaque entree dans la table.

Je capte pas Comment ça l'index lui permet de s'assurer que le ORDER BY sera dans la bon ordre ? Mettons que j'ai pas fait un ALTER TABLE en ordonnant en ma table ...
 
Si j'ai des enregistrements déclassé, comment ça se passe ?
 
J'ai trouve ça sinon :
 

disons que si, il va parser tout l'index parce que tu n'a pas de where, mais les résultats seront directement dans l'ordre grace à l'index.

Comme dab, je capte rien à ton charabiat S'il fait un file sorting, de toutes les manières, il va scanner toute la table ? On en revient au même point nan ?

On est dans l'histoire du bTree là donc ?
 
J'aurai du trouver un autre exemple
 
Si je fais un ORDER BY nom_de_famille DESC ? (Sur un champ CHAR ou VARCHAR)

 
Le principe d'un index c'est de garantir que les resultats soit classes suivant cet index (dans l'index file hein, pas dans le data file).
Donc si tu ne tappes QUE dans l'index file, tu es sur que ton order by sera ultra rapide et qu'il n'aura pas besoin de faire de file sorting.
Si tu tappes dans le datafile ca sera plus lent a cause des seeks disques supplementaire, mais il ne fera pas non plus de file sorting s'il doit retourner moins de 2/3 (je crois) du total resultat de la db et que tu as un index comme il faut. Et si tu n'as pas d'index adequat, alors il fera du filesorting, et c'est la methode qui est decrite un peu plus haut.

oui, mais ce que dit joce c'est que dans les cas simples, en fait ça sert à rien.

dans son cas, vu qu'il n'a pas de WHERE, il n'utilisera jamais d'index

a partir du moment ou t'as pas de WHERE il ne touchera jamais a l'index file.

 
Hum OK ... Si j'ai un SELECT truc FROM machin WHERE key=3 ORDER BY id DESC. Là, il se passe quoi alors ? Tu places ton index (groupé) ou tes index sur quel(s) champs ?

Y a une tres legere difference entre faire un scan du fichier d'index et faire un scan du fichier de donnee (le deuxieme etant generalement bcp plus gros).
Le file sorting ca veut dire qu'il doit creer une table temporaire pour stocker les resultats avant de les retourner.
Dans ton cas comme il a besoin du datafile et de l'indexfile, et que tu lui demandes tous les resultats, il n'utilisera jamais ton index, et donc utilisera du filesorting.

Petit nuance : enfin sauf si toutes les donnees demandees sont disponibles dans le fichier d'index directement, et la ca devient tres interessant.

si tu mets pas d'index :  
 
FULL SCAN du datafile
 
si tu mets un index sur (key)
 
utilisation de l'index pour recup les resultats dans le datafile, et file sorting (donc creation d'une temporaire) pour ordonner le tout
 
si tu mets un index sur (key, id)
 
utilisation de l'index pour recup les resultats dans le bon ordre dans le datafile, donc pas de file sorting pour ordonner le tout
 
si tu mets un index sur (key, id, truc)
 
utilisation de l'index pour recup tous les resultats dans le bon ordre. Pas besoin de passer par le datafile.
 

et si tu fais un EXPLAIN tu verras respectivement (de memoire, ca doit ressembler a ca) :
 
ALL
-
 
Ref
Using Where; File sorting
 
Ref
Using Where;
 
Ref
Using Where; Using index

Vous vous prenez la tête pour pas grand chose.
 
Bon Joce, file nous la structure de ta table, les sources en PHP et on pourra voir de quoi tu parles, ça ira plus vite.
 

mince alors je les ai perdu

Spa grave, j'vais aller faire un chèque à Caradisiac pour qu'ils me laissent regarder leur bdd, j'aurais au moins la structure de la table.
 
 

Les explications de Joce sont tentante, mais attention à ne pas abuser des index multicolones : ca serait bête d'avoir un fichier d'index 10 fois plus gros que la table correspondante rien que pour avoir dans l'index toutes les colones d'une requette exécuté une fois par mois.
 
PS : J'ai appris des trucs aujourd'hui.

En résumé, les index multicolonnes sont utiles sur des requetes éxecutées fréquemment?

Et dans les trois cas qu'a donné Joce, quel est le cas le plus avantageux sur une requete executée fréquemment?

Sur une requette exécuté fréquemment (par exemple liste des discutions d'un forum classé par date de derniére réponse), c'est le troisiéme cas (tout avoir dans l'index) qui est le plus intéressant car plus rapide que les autres.

Ok

Et pour une requete peu sollicitée, un index sur le champ indiqué dans la clause WHERE ou dans la jointure, et voila. C'est ça?

Tain, je suis à la ramasse, niveau code

Bonsoir,  
 
A vous les pros des SGBD, helas Mysqlla plupart, mais bon je tente quand même
 
Qqu a une idée pour appeler une procédure stockée sous SQL Serveur depuis PHP.
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
 
MERCI a vous
 

Ah oui, mais nan, c'est pas blabla ici, on parle développement de forums uniquement ici

 
attends qu'il ressorte son super éditeur de texte  

Bonjour,
 
VOus gérez comment la selection des topics avec drapeaux et sans?(afficher tous les posts, avec sois une icone lu, sois rien avec non lu)
 
Je ne demande pas comment on fait, (j'ai une table sujet, une autre drapeaux avec auteur, topic, date..). ce qui me pose probleme cest la requete sql et l'affichage.  
 
Si je fais une jointure, je nai que les drapeaux. Comment afficher tous les posts?
 
Merci bien

 
CP1250 ?

LEFT JOIN au lieu d'une jointure de base ?

ouai ainsi que le developpement du forum v5  

héhé parlons SQL ^^
 
Je viens de faire quelques tests pour l'affichage des topics. Ma requete sans utilisation de limit ou de champs difficile à mettre à jour fonctionne nikel ^^
 
Sur un topic de 80 000 rep, en dernière page là ou il faudrais 0,9sec avec un limit, il me faut 0,03 sec (constant sur toutes les pages)^^.
 
Bon il faut savoir que je commence tout juste et que il doit y avoir moyen de largement améliorer cette requète.
 
Wait and see ^^

ba elle est ou la requete

et c'est toi qui demande en plus lol
 
Envoie d'abord les sources de MD  

Bah tu dis "parlons SQL" et il y a pas de SQL dans ton message

 
Ben là actuellement je peu rien vous montrer je ne suis pas depuis MON pc. Je peu simplement vous dire que j'utilise pas de limit ni de between. Et j'utilise du texte pour faire passer mes variables, enfin c'est surement abstrait, mais je vous fais une démo ce weekend promis, dés que je récupère le net sur mon pc
 
Edit: je t'ai lu limit

ok j'avais supprimé parce que c'était none of my business mais content de voir ta réponse

C'est de la curiosite, j'ai pas besoin de tes optimisations pour mon forum

J'ai une petite question.
 
Les procedure stockées sont utiles dans quelles cas ? Des qu'il y a des calcul sur les resultats (SUM,MIN ... ) ?  
Dans les requetes imbriqués aussi non ?
 
Mais pour de simples select * from ma_table, ca sert pas a grand chose ? C'est bien ca ?