Discussion :

[einboubou]

Bonjour,

je voudrais savoir si on peut connaitre le nom de ligne qu'un select pourrait prendre même si on a un limit.

Par exemple sur une table avec 10 entrées. Si on lance

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from table limit 0,5

Y a t'il un moyen de connaitre le nombre d'entrée (10 dans ce cas) sans avoir à refaire une requête ?

[qi130]

La table INFORMATION_SCHEMA.TABLES permet de connaitre ce nombre.

Mais, il n'est "valable" que pour un select sans condition, et exige de toute façon de requêter sur cette table.
Alors, autant faire un count

[einboubou]

ok alors je ferais un count en php tout bête :p

[mrcmrc]

La table INFORMATION_SCHEMA.TABLES permet de connaitre ce nombre.

Mais, il n'est "valable" que pour un select sans condition, et exige de toute façon de requêter sur cette table.
Alors, autant faire un count

Mauvaise réponse !!!

La doc MySQL:

mysql> SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name
-> WHERE id > 100 LIMIT 10;
mysql> SELECT FOUND_ROWS();

[einboubou]

pour le count en php c etait bete j avais oublie le limit :p

y a un moyen de s assurer que personne ne fait de select entre le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name
-> WHERE id > 100 LIMIT 10;

et le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT FOUND_ROWS();

ou alors faudrait que je bloque la table en lecture Vous en pensez quoi ?

Je crois pas, en plus ca a pas l air de marcher chez moi :/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT SQL_CALC_FOUND_ROWS * 
FROM pomelodev_joboffer
WHERE JO_id >100
LIMIT 0 , 30

donne Zeige Datensätze 0 - 29 (251 insgesamt, die Abfrage dauerte 0.0040 sek)

soit 251 résultat en tout et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT FOUND_ROWS( )

donne
FOUND_ROWS()
126

je fais une erreur quelque part ?

[CinePhil]

Pour avoir le nombre de lignes de la table, il faut écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT COUNT(*)
FROM pomelodev_joboffer

Mais effectivement, si entre cette requête et le SELECT sur un nombre plus restreint de lignes il y a un INSERT par un autre utilisateur, le résultat de la première requête sera faux.

2 solutions :
1) Bloquer la modification de la table, le temps de faire les deux requêtes.
2) Si la table ne contiendra jamais un trop grand nombre de lignes, rappatrier toutes les lignes de la table (SELECT sans LIMIT) pui sn'afficher que le nombre de lignes voulues par une boucle en PHP.

Sinon si le nombre de lignes de la table n'a pour vous qu'une valeur indicative et n'a pas besoin d'être précise, lancez les deux requêtes à la suite sans blocage de la table. Le cas ou des INSERT viendraient modifier ce nombre sera peut-être rare et ne changera pas de manière conséquente l'information voulue.

[mrcmrc]

Hello,
suite aux résultats étranges obtenus (126 avec FOUND_ROWS au lieu de 251), j'ai testé chez moi... et j'ai 127 au lieu de 907 en passant par phpMyAdmin. Probablement que phpMyAdmin fait une autre requête avec SQL_CALC_FOUND_ROWS et que c'est ce résultat que nous voyons. En refaisant le test directement dans un script PHP, ça marche sans problèmes.

D'autre part le résultat du SELECT FOUND_ROWS n'est pas influencé par les INSERT/REPLACE/DELETE/... qui ont été faits depuis le SQL_CALC_FOUND_ROWS, il n'y a pas besoin de poser un verrou. Si je comprends bien, la deuxième requête ne fait que récupérer un résultat calculé lors de la première requête.

Tests avec une table de 907 enregistrements.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
SELECT * FROM test
=> 907
 
SELECT SQL_CALC_FOUND_ROWS * FROM test LIMIT 10,20
=> 20
 
SELECT FOUND_ROWS() AS nombre
=> 907
 
SELECT SQL_CALC_FOUND_ROWS * FROM test LIMIT 10,20
=> 20
 
DELETE FROM test WHERE id<20
=> 19
 
SELECT FOUND_ROWS() AS nombre
=> 907 (: c'est le total AVANT le DELETE !)
 
SELECT * FROM test
=> 888

[qi130]

Mauvaise réponse !!!

Mais non, cette réponse est parfaitement valable eu égard à la question posée.

Il s'avère qu'une autre possibilité existe avec SQL_CALC_FOUND_ROWS, mais avec les "aléas" constatés par les essais rapportés.