Reprise du message précédent :
 
c'est quoi comme forum? j'ai cherché, j'ai pas trouvé de nom. c'est du fait maison ?

c'est un vBulletin

En gros t'es en train de nous expliquer que toutes les optimisations à la con pour éviter d'utiliser un LIMIT sont inutiles car en fait le parcours total d'un index reste malgré tout relativement rapide et que c'était le rapatriement de tout qui faisait tout ramer?  

Tiens ça marcherait pas en une requête en utilisant 2 fois la même table sous des noms différents?

Enfin ça prend quand même que 0.01s quand on connait directement les bonnes clés, un between doit quand même aller plus vite. Fin faut voir le mechanisme que t'as derrière pour utiliser le between.

 
C'est impossible, un LIMIT sera beaucoup plus lent (et plus la quantité de données présentes dans la table augmente plus c'est vérifiable)

Déjà testé : non
Parce que le limit s'applique au resultat de la jointure et donc il est obligé de faire la jointure et de chopper tous les résultats avant de faire le LIMIT.

yep, un BETWEEN reste clairement la solution ultime.
Mais c'est interessant comme résultat, ca vaudrait le coup que MySQL se penche dessus pour affiner leur optimiser

ça donnerait une raison d'exister aux forums PHPBB, IPB, SMF et j'en passe ^^

Quel idiot je suis    . En écrivant la requête même mentalement jusqu'au bout (jusqu'au LIMIT) on se rend compte que ça ne peut pas marcher  

depuis plusieurs page vous parlez de limit, mais vous appliquez cela a quel partie du forum ? vous essayer d'optimiser quelle partie? un gros topic ?

tout ce qui est paginé je suppose.

ba tant qu'on est pas arrivé au LIMIT c'est bien

On peut pas fouttre un LIMIT dans une requête imbriquée?  

malade

Si, mais ca revient plus ou moins a passer par un TEMP table.

Je trouve ça plus propre. Enfin le mieux serait que les gars de mysql changent leur optimiseur sur un cas pareil.

ouaip mais ca doit pas etre trivial non plus.
Dans le cas de :
 
- SELECT x,y FROM foo ORDER BY z LIMIT 10000,10
 
Il ne peut appliquer cette optimisation que :
 
- si il y a un index sur (z,x)
- si x est une primary key
 
Qui plus est ca l'oblige a passer par une temp table en interne, et entre une temp table et pas de temp table, generalement il choisit toujours la solution 2.
Dans notre cas, ca doit pas etre evident de savoir quand est-ce que le cout du scan du LIMIT va etre inferieur au cout de la creation de la temp table en interne.

Vu qu'il ramène toutes les données ça me semble assez vite vu. Peut être choisir des valeurs seuils pour le limit   . Enfin, si ça na pas encore été fait, c'est qu'il doit y avoir une raison genre celle que tu as énnoncée.

Pas forcement, ca depend aussi du deuxieme parametre du limit.
Un LIMIT 100000,10000 par exemple ca serait pas une bonne idee de creer une temp table a mon avis.

c'est ce que je disais, ils doivent inventer une formule pour savoir dans quel cas faire quoi

Avec vos histoires je suis en train de me demander comment je pourrais arranger les requêtes sur imcdb.org (note : à la base c'est pas moi qui ai fait le truc, même si j'ai en fin de compte j'ai quasi tout refait petit à petit).
 
Pour le moment une des grosses pages fort utilisée est celle qui affiche les derniers commentaires postés sur les différentes fiches. Donc je fais un tri en inverse sur l'ID (pour afficher les derniers d'abord), avec un LIMIT pour la découpe en page, et un SQL_CALC_FOUND_ROWS pour savoir combien y aurait eu de résultats au total.
J'imagine que c'est très mal  
D'autant plus que la jointure avec la table "users" est faite sur le pseudo et non sur un ID (faudra que je corrige ça, c'est pas moi qui ai fait ça à la base).
Donc si je faisais une table temporaire comme Joce en parlait, ça serait mieux j'imagine ?
Pour cette table-là je vois plus ou moins comment je pourrais faire des numéros de message (il suffirait de faire un select pour voir le max avant vu que le tri est inverse).
Par contre pour les pages qui affichent les listes de véhicules, je ne vois pas comment je pourrais virer les LIMIT Si je prends tous les record où vehicle_make = 'Renault' AND vehicle_model like 'Mégane%' + un LIMIT, je vois pas trop comment optimiser (je sais, c'est pas un forum, mais comme y a des commentaires sur chaque page ça s'en rapproche un peu )

Tout dépend de la taille potentielle des requêtes retournées et du nombres de données que tu vas afficher. Déjà si la plupart du temps ta requête est du type LIMIT 0,x c'est pas super intéressant.

Ouais dans la majorité des cas ça commence à 0 pour les commentaires (où il y a énormément d'enregistrements), vu qu'on consulte surtout la 1e page. Et pour les autres pages, il y a pas tant de données ni même d'enregistrement en fin de compte...
Je vais quand même rajouter le temps de génération des pages, juste pour voir

'tain, je crois que j'ai une idée pas mal et assez trenscendante, fait chier de pas pouvoir tester tout de suite !

En connaissant un peu les trucs à ne pas faire, il n'y pas spécialement besoin de tester parfois.  
 
Je fais pas de forums mais le problème de limit dans le cas de pagination m'intéresse un peu pour le fun. J'ai jamais trouvé de solutions sans limit pour le régler. Tout juste je peux limiter la taille maxi du limit à effectuer

Petite question concernant l'URL rewriting... L'intérêt des URLs type www.monforum.com/cat-xx.htm est assez limité. Comment faites vous pour avoir le résultat suivant: www.monforum.com/section-trucbidule.htm directement à partir du nom d'un topic, d'une catégorie ou autre?

Pour HFR, il y a pour chaque section un champ texte (contenant "trucbidule" dans ton cas) en plus du nom de la catégorie et de son ID qui permet - je suppose - de faire la traduction dans les deux sens.

Apache mod_rewrite, entre autres.

Salut à tous :-)
 
Je viens de mettre encore à jour mon forum, avec, comme pour HFR, en plus des "onglets" permettant de réunir les drapeaux, bah j'ai rajouté les drapeaux quand on liste un topic (directement à côté, avec l'icône favori qui prend la priorité itou itou) ^^
 
Voilà, il fait beau mais j'ai dit à mon cousin que j'allais le chercher en fin d'après midi, donc je code un peu en attendant

 
En local ça m'a bien réduit mon temps de génération... puis lors du test chez OVH :

Mysql 3.23 ?

Non, 4.0 (contre 4.1 en local)
Par contre ils ne donnent peut-être pas le droit de créer ces tables temporaires ?

 
chez moi les catégories peuvent etre identifiées par une chaine de caracteres, d'ou son apparition dans le rewrite

On peut indexer directement sur ce champ pour s'en servir à la place d'un id numérique aussi, si on utilise uniquement du pretty print (des jolies URL quoi) le numéro d'ID de la cat ne sert pas à grand chose

C'est exactement ce dont il parlait.

Il me semble que même indexé, la recherche sur une colone de texte sera plus lente que la recherche équivalente sur une colone numérique.

Tiens au passage ça m'arrangerait d'avoir la réponse à cette question avant que je me fasse chier à remplacer les jointures sur les pseudos d'utilisateurs par des jointures sur les ID d'utilisateurs

Et si on tape que des caractères étrangers (japonais par exemple) dans un titre, ça risque pas de poser problème pour la conversion en URL ?
Genre ça 検索オプション (texte copié sur Yahoo Japan, me demandez pas ce que ça signifie même si c'est probablement "recherche avancée" )
 
Pour l'indexation sur du texte, je pense en effet que ça doit être plus lent que sur du numérique.

url-> utf-8

Tiens, je viens de trouver un bug.
 
guillemets + parenthèse fermante (ou plus exactement n'importe quoi réécrit en &xxxx; suivi de parenthèse fermante) est interprété comme un
 
PS : je suis content, ça le fait pas sur mon forum
EDIT : Merde, j'ai parlé trop vite, ça le fait sauf pour les guillemets chez moi Ca va être chiant (et lourd) à éviter.

Ça fait longtemps qu'il est là ce bug

C'est plus que probable, mais la question n'est pas de savoir si c'est plus lent mais si c'est suffisament rapide.

Pour les catégories, il n'y en a pas des millions, donc ça ne devrait pas poser trop de problèmes