Salut,
J'utilise mysql 4 et il y a truc qui me dérange dans mon code actuel. Pour savoir combien de résultats j'aurais avec une commande j'utilise bien sûr count(*). Mais voilà, au delà d'un certain chiffre, ça ne m'intéresse plus de savoir si j'aurais 100 ou 10 000 résultats : je veux juste savoir si j'en aurais plus de 100.
Je me demande s?il n'y a pas moyen de spécifier qu'il n'est pas utile de compter au-delà de 100. Parceque sur des requêtes élaborées avec beaucoup de résultats, je commence à voir ma base ralentir.
 
Y a-t-il un moyen ?

J'ai trouvé un moyen bien crade :

Voili, voilou, j'aimerais bien trouver mieux.

C'est vraiment plus performant
 
(en tout cas, elle me plait beaucoup cette syntaxe )

limit (5, 10)
 
les 10 suivants à partir du 5ème si ça peut t'aider

D'après ce que je vois c'est vraiment minime...
Mais je ne l'ai pas encore testé sur mes grosses requêtes.

Merci, mais ceci limite les lignes retournées, et non pas les lignes comptées (par COUNT).

oui logique. sorry

wow !
Avec une requête bien tordue où COUNT(*) me donne 13 000 résultats, si je limite le nombre de résultats à 1 000, le temps d'exécution est divisé par 5 !

 
et ca donne ? un gain effectif de ?

1er requête : 0.06 sec.
2em requête (limitée à 1000) : 0.01 sec.
 
Je signale que je suis dans de mauvaises situations pour tester : sous Windows XP (oui, je sais...). Je teste sous Linux dès que possible.

Ma méthode marche bien, mais ça m'étonne qu'il n'existe pas déjà qqchose !
 

Sinon quelqu'un pourrait m'expliquer pourquoi, cette requête me donne une fois sur deux N_RES à 0 ?

Je précise que cette requête là me donne toujours N_RES à 100...

Chez moi, elle ne fonctionne pas 1 fois sur 2, mais seulement la première fois (comme si le "@nb := 0" n'étais jamais exécuté)
 
edit : c'est encore plus subtil que ca  
Si @nb est < 50 (pas forcément 0) avant la requête, ca donne le bon résultats. Si @nb est >= 50, la requête donne toujours 0

En tout cas, c'est bizarre.

En mettant "... WHERE @nb <> 100", là, elle fonctionne 1 fois sur 2 (si pas de réinitialisation de @nb entre temps)

J'ai pas ces comportements...
Pour moi, une fois ça marche pas (N_RES à 0), et une autre, ça marche (N_RES à 100). Dans le premier cas, "SELECT @nb;" me donne 0 et dans le second 100.
Par contre, il suffi que je réinitialise @nb à n'importe quel chiffre inférieur à 100 (avec "SET @nb = xx" ) pour que le résultat suivant soit bon (N_RES à 100).
J'en conclu que la condition (@nb < 100) est évaluée avant l'initialisation (@nb := 0).

Pour tout faire en une seule requête (et deux lignes de résultat) :

QQ1 voit autre chose ?

a mon avis, c'est le cas lorsqu'aucune ligne ne respecte le WHERE.
Par contre, s'il y en a, il ne réexécute pas le "@nb := 0" (sinon, l'incrémentation serait réinitialisée à chaque fois)

Je pense que c'est logique puisque la requête retourne quand même une ligne (COUNT retourne 0).
 
Donc, si @nb est supérieur à 100, il n'y a aucune ligne correspondante (puisque @nb < 100 est faux), MySQL exécute COUNT (qui retourne 0), et "@nb := 0".
Pour la requête suivante, @nb est inférieur à 100, donc ça roule...

Je up au cas où, depuis le temps, un nouveau aurait une solution plus "standardisée".

salut
pas de solution pour toi
mais si t'es sous sql server,t'a essayé de tapper dans les tables systemes pour voir le nombre d'enregistrements retournées pour ta table. Si les statistics, sont en auto-update, ca devrait etre relativement fiable. M'enfin dans ton cas pour determiner si il y a seulement plus de 100 records, ca va pas aller bcp plus vite.