Question mysql_num_rows

Version imprimable

02/02/2006, 22h21
LordBob

Question mysql_num_rows

Bonjour a tous,
en fait j'aimerais juste savoir, pour connaitre le nombre de resultat que l'on a à une requête, on fait mysql_num_rows + 1?
car j'ai l'impression que si j'ai une seul ligne de resultat, bah mysql_num_rows me renvoie 0.
Vous confirmer?
Merci par avance
Bob

non je ne suis pas d'accord

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<?php
 
$link = mysql_connect('localhost', 'root', '');
if (!$link) {
   die('Impossible de se connecter : ' . mysql_error());
}
 
// Rendre la base de données foo, la base courante
$db_selected = mysql_select_db('test', $link);
if (!$db_selected) {
   die ('Impossible de sélectionner la base de données : ' . mysql_error());
}
 
$sql = "SELECT * FROM celko1in10 LIMIT 0,1";
$query=mysql_query($sql);
echo mysql_num_rows($query); // affiche 1
?>

02/02/2006, 22h44
LordBob

en fait c t pour faire un controle, mais c'est pas grave, je me suis démerder autrement.
pourtant c'est bizar par que je tester si le nombre de ligne était inférieur ou égal à 0 pour savoir si ma requete avec un resultat, mais elle avait beau avoir un resultat, ca me mettai l'erreur.
mais bon j'ai changé ma façon de faire.
désoler pour le dérangement et merci pour la réponse rapide!
02/02/2006, 23h01
ePoX

Ouè, vu que je ne sais pas de quel code tu parles je ne sais que te répondre :roll:
02/02/2006, 23h18
mathieu

Citation:

Envoyé par LordBob

pourtant c'est bizar par que je tester si le nombre de ligne était inférieur ou égal à 0 pour savoir si ma requete avec un resultat, mais elle avait beau avoir un resultat, ca me mettai l'erreur.

c'était peut-être la requête qui avait un problème
pour gagner du temps je te conseille de lancer tes requêtes comme indiqué dans la FAQ comme ça en cas d'erreur tu vois tout de suite ce qu'il se passe :
http://php.developpez.com/faq/?page=...ysql_ressource
02/02/2006, 23h35
Moloc'h

Et aussi de voir du côté de la fonction mysql_affected_rows(), moins gourmande en ressources semble t'il que mysql_num_rows().
02/02/2006, 23h38
ePoX

C'est pas le même usage :s non ?
02/02/2006, 23h42
Moloc'h

mysql_num_rows n'est valable que pour les SELECT... tandis que mysql_affected_rows fonctionne pour les requêtes les plus fréquentes (SELECT, INSERT, UPDATE etc)
02/02/2006, 23h45
LordBob

mathieu << je suis sur que cela ne vient pas de ma requête pour preuve, elle fonctionner tres bien avant que je ne me serve de mysql_num_rows().

Moloc'h << merci pour l'info. je tacherai d'utiliser celle, car si elle marche pour n'importe quel requête, ca peut être tres interressant !
02/02/2006, 23h49
Moloc'h

On peut voir à quoi ressemble la requête ? Un peu de code ?
02/02/2006, 23h58
LordBob
bien sur ma de probleme, voici la requete:

Code:

SELECT IdUtilisateur FROM UTILISATEUR WHERE LoginUtilisateur='xxxx' AND PasswordUtilisateur='yyyy';

ensuite voila le code:
Code:

1 2 $result = mysql_query($requete); return(mysql_num_rows($result));
et puis loins je fait:
Code:

1 2 if(fonction(param) <= 0) // erreur
et voila ce qui bug!
or si j'enlévé le if, ça marche très bien!
03/02/2006, 09h29
ePoX

C'est ptet que les logins n'était pas bon pendant tes test :lol: :lol:

:arrow:
03/02/2006, 10h29
LordBob

nan, aucune chance.
03/02/2006, 10h31
Kioob

Citation:

Envoyé par Moloc'h

mysql_num_rows n'est valable que pour les SELECT... tandis que mysql_affected_rows fonctionne pour les requêtes les plus fréquentes (SELECT, INSERT, UPDATE etc)

euh... le affected rows n'est en théorie pas affecté par un SELECT... d'ailleurs d'après la doc ce n'est pas le cas.

Et de manière générale : autant mysql_affected_rows() est souvant utile, autant mysql_num_rows() est rarement approprié.
03/02/2006, 10h46
Yogui

Salut

mysql_affected_rows() retourne le nombre de lignes affectées (donc uniquement en écriture, le DELETE étant considéré comme telle) tandis que mysql_num_rows() retourne le nombre de lignes sélectionnées (donc uniquement en lecture).

@LordBob : mysql_num_rows() ne rendra jamais un résultat inférieur à zéro (cela n'aurait pas de sens), tu peux donc faire le test sur == 0 plutôt que sur <= 0

Kioob : de mon côté, j'utilise bien plus souvent mysql_num_rows() que mysql_affected_rows().
03/02/2006, 11h05
Kioob

Citation:

Kioob : de mon côté, j'utilise bien plus souvent mysql_num_rows() que mysql_affected_rows().

Et bien pour moi mysql_num_rows() ne sert pas à grand chose : quand tu veux connaitre le nombre d'enregistrement, une requete count() est bien plus performante, notament parce qu'elle évite le rappatriement des données. Cette fonction n'est donc utile que lorsque l'on veut de toutes façons rappatrier les données ET que l'on veut également les compter (ça évite que MySQL recherche 2 fois les données).
De plus, pour pouvoir l'utiliser il faut utiliser mysql_query() qui bufferise le résultat... hors j'ai tendance à utiliser mysql_unbuffered_query(), plus rapide et moins gourmande en mémoire.

Pour mysql_affected_rows(), son utilisation n'est pas fréquente, mais est toujours appropriée.
03/02/2006, 11h36
Yogui

Nous entrons dans le vif d'un sujet qui m'intéresse mais qui n'a plus grand chose à voir avec celui du départ :/

Je me disais, peut-être naïvement, que mysql_num_rows() retourne une valeur qu'il a calculé de toute manière. Ainsi, un appel à mysql_num_rows() serait plus rapide (ou réellement plus simple à gérer) qu'une nouvelle requête SELECT COUNT(). À moins que tu parles d'inclure le COUNT() dans la requête courante, ce qui implique souvent l'implication de GROUP BY et qui, par conséquent, a un gros effet sur les performances (je compare avec un appel à mysql_num_rows())...

Concernant mysql_unbuffered_query(), j'avoue avoir du mal à en saisir l'efficacité... Étant donné que je parcours de toute manière mes résultats pour les afficher, autant que MySQL les mette en cache : cela me permettra d'utiliser mysql_num_rows() sans avoir d'implication réelle sur les performances (puisque les résultats sont en cache, pas besoin d'aller les chercher physiquement dans la BDD, ce qui serait nécessaire avec mysql_unbuffered_query()).

J'ai l'impression que la différence entre nos points de vue se situe dans le fonctionnement de mysql_num_rows() : à quel moment MySQL et/ou PHP calculent-ils ce résultat ?
Je suis d'avis que c'est plus ou moins fait pendant l'exécution de la requête, tandis que tu sembles d'avis que c'est fait a posteriori (lors de l'appel à la fonction).
03/02/2006, 11h49
ouatmad

Citation:

J'ai l'impression que la différence entre nos points de vue se situe dans le fonctionnement de mysql_num_rows() : à quel moment MySQL et/ou PHP calculent-ils ce résultat ?
Je suis d'avis que c'est plus ou moins fait pendant l'exécution de la requête, tandis que tu sembles d'avis que c'est fait a posteriori (lors de l'appel à la fonction).

je suis tout a fait d'accord avec toi Kirkis. mysql_num_rows est bcp plus efficient q de faire un select count. et de toute façon c'est bcp plus pratique. de toute façon les avis resteront partagés.
03/02/2006, 12h18
Kioob

Effectivement on s'écarte un poil du sujet... mais si c'est pour s'expliquer, ça va encore :)

Je commence par éclaircir un point :
dans tous les cas mysql_num_rows() retournera le nombre total de lignes, donc un simple COUNT() donne le même résultat, aucunement besoin de faire des GROUP BY fort consommateurs.

Donc, pour mieux comprendre les différences, voici quelques précisions :
- COUNT() est une fonction SQL, exécutée par le serveur MySQL (donc sur la machine faisant tourner MySQL).
- mysql_num_rows() est une fonction PHP, exécutée par PHP (donc généralement sur le serveur faisant tourner Apache).

La fonction mysql_num_rows() en elle même est extrèmement rapide et non consommatrice : elle ne fait que retourner la valeur d'un compteur stocké par PHP**.
Le problème, c'est que c'est la fonction mysql_query() qui rempli ce compteur :
1) elle exécute la requete SELECT auprès du serveur MySQL comme demandé
2) elle télécharge et conserve en mémoire toutes les lignes de résultats (qu'il y en ait seulement 5 ou 3 millions, le résultat est le même)
3) au fur et à mesure de ce "téléchargement", elle met à jour le compteur "num_rows"

=> Avantage : le résultat une fois stocké en local, on peut en faire ce qu'on veut : "se déplacer" dedans, revenir en arrière, afficher plusieurs fois les mêmes lignes, etc etc.
=> Inconvénients :
- le serveur va faire des accès disque pour lire les enregistrements demandés
- le client va télécharger des données éventuellement conséquentes (= consommation de la bande passante)
- le client va consommer de la mémoire pour stocker tous ces enregistrements

Tandis qu'avec une requete COUNT(), pour peu que des INDEX correspondent aux critères de recherche, le serveur ne fera même pas d'accès disque, il va simplement retourner une (et une seule) valeur : le nombre d'enregistrement.
Avantages :
- pas d'accès disque pour le serveur
- quelques octets à transfèrer uniquement
- une seule ligne de résultat coté client à stocker

Mais il y un inconvénient : si le client fait une requete COUNT(), il n'obtient évidement que le nombre d'enregistrements... mais certainement pas les enregistrements en question. Et c'est là qu'intervient mysql_num_rows() : dans le cas où le client veut à la fois le nombre d'enregistrements et la liste des enregistrements, alors cette fonction est bien souvent adaptée. Car par contre il serait ridicule d'exécuter un COUNT() suivi du SELECT permettant de récupèrer les enregistrements...

Pour mysql_unbuffered_query(), c'est une autre histoire : avec mysql_query() c'est le client qui met le résultat de coté, au cas où le script voudrait y accèder plusieurs fois d'affilée (au sein d'une même "instance" du script hein, ce n'est pas un cache local non plus). Or, dans le cas d'un site web c'est rarement le cas. Comme tu le dis, dans 80% des cas on va simplement afficher le résultat... donc inutile de consommer de la mémoire pour stocker ces données, autant les afficher directement.

** je précise que je n'ai pas regardé le code source de PHP en détail, donc quand je dis que c'est PHP qui compte, stocke en mémoire, etc, il se peut qu'il s'agisse de fonctions offertes par l'API MySQL utilisée dans PHP. Néanmoins le résultat est le même, ce travail est effectué sur le client et non sur le serveur.
03/02/2006, 12h45
Yogui
Juste pour que tout le monde suive bien : dans la démonstration de Kioob, le "serveur" est MySQL et le "client" est PHP.
Je reformule : nous ne parlons pas de PHP côté serveur (comme à l'accoutumée lorsqu'il s'agit de Web) mais de PHP en tant que client qui pose des questions à MySQL.

Lorsque j'évoquais le GROUP BY, c'était pour comparer les stratégies suivantes dans le cas où l'on souhaite savoir combien il y a de tuples :
- mysql_query() puis mysql_num_rows()
- mysql_unbuffered_query() avec la même requête que ci-dessus incluant une colonne COUNT() et, par conséquent, un GROUP BY
Nous sommes visiblement d'accord sur ce point : il est préférable d'éviter ce type de COUNT()
Il y a une autre solution que tu as évoquée comme "ridicule" et j'adhère à ton avis sur ce point.
On a side note: je considère la seconde des méthodes ci-dessus comme étant tout aussi ridicule.

Merci pour la précision sur le fonctionnement de mysql_num_rows(), il correspond à ce que je soupçonnais.
J'avais supposé que tu lui attribuais un fonctionnement différent à cause de cette remarque :

Citation:

Envoyé par Kioob

ça évite que MySQL recherche 2 fois les données

Je me suis visiblement trompé. Que voulais-tu dire ?

Maintenant, au sujet des différences entre mysql_query() et sa version non bufferisée...
La doc recommande de parcourir tous les tuples "retournés" par mysql_unbuffered_query() (j'utilise les guillemets car, techniquement, les tuples ne sont pas exactement retournés).
Quelle est la différence avec une requête mise en buffer puis parcourue ?
J'y vais de mes suppositions :
- cas mysql_unbuffered_query() :
  [list:e7315c3760]
- à chaque appel à mysql_fetch_assoc(), il va falloir aller chercher le résultat sur le disque
- un accès distinct pour aller chercher chaque tuple
[*]cas mysql_query() :
- à chaque appel à mysql_fetch_assoc(), pas besoin d'aller jusqu'au disque puisque tout est en cache.
- un seul accès pour aller chercher tous les tuples de manière ensembliste : ça s'optimise comme ça veut mais ça s'optimise forcément, non ?
[/list:u:e7315c3760]
03/02/2006, 13h19
Kioob
Citation:
Lorsque j'évoquais le GROUP BY, c'était pour comparer les stratégies suivantes dans le cas où l'on souhaite savoir combien il y a de tuples :
[...]

mysql_query() puis mysql_num_rows()
mysql_unbuffered_query() avec la même requête que ci-dessus incluant une colonne COUNT() et, par conséquent, un GROUP BY
Nous sommes visiblement d'accord sur ce point : il est préférable d'éviter ce type de COUNT()
Il y a une autre solution que tu as évoquée comme "ridicule" et j'adhère à ton avis sur ce point.
On a side note: je considère la seconde des méthodes ci-dessus comme étant tout aussi ridicule.
C'est justement là que je ne suis pas d'accord : à aucun moment on a de GROUP BY avec la deuxième méthode... (au passage, on peut très bien faire un COUNT() avec mysql_query() d'ailleurs hein).
- Cas 1 (simplifié) : mysql_query( "select id from article where type = 'toto'" ); $nb = mysql_num_rows();
- Cas 2 (simplifié aussi) : mysql_query( "select count(*) from article where type = 'toto'" ); $nb = mysql_fetch_assoc();
  
  => Il n'y a aucun "group by" ici. De plus, le critère en question est même sûrement indexé, et donc MySQL n'ira même pas "compter les lignes" dans la table mais lira juste les infos dans l'index.
Citation:

Merci pour la précision sur le fonctionnement de mysql_num_rows(), il correspond à ce que je soupçonnais.
J'avais supposé que tu lui attribuais un fonctionnement différent à cause de cette remarque :

Citation:

Envoyé par Kioob

ça évite que MySQL recherche 2 fois les données

Je me suis visiblement trompé. Que voulais-tu dire ?

Je voulais dire par là qu'il évitait justement de faire un "SELECT de récupération des données" suivi d'un "SELECT de comptage". Et je répète que c'est pour moi le seul cas où mysql_num_rows() est utile.

Citation:

j'utilise les guillemets car, techniquement, les tuples ne sont pas exactement retournés

peux tu préciser ta pensée stp ?

Citation:

Quelle est la différence avec une requête mise en buffer puis parcourue ?

Pour moi que l'appel soit fait via mysql_query() ou mysql_unbuffered_query() ne change pas grand chose coté serveur : le serveur lit les données sur le disque, et toutes les N lignes (suivant la taille de son tampon réseau) il envoit un paquet au client.

Ce qui change c'est la façon dont le client gère la réception des paquets :
- cas mysql_unbuffered_query() : le socket est lu à chaque appel de mysql_fetch_assoc()
- cas mysql_query() : le socket est lu d'une traite par la fonction mysql_query(), et son contenu intégralement copié en mémoire. Chaque appel de mysql_fetch_assoc() va chercher les tuples en mémoire.
La seule différence notable d'après moi est la consommation mémoire sur le client.
03/02/2006, 13h40
Yogui
Flûte, nous allons avoir du mal à nous en sortir si nous continuons à mal nous comprendre :/

Je pensais que tu n'appréciais pas le coup de faire deux mysql_unbuffered_query() à la suite, l'un servant à récupérer les données et l'autre à compter les tuples.
Je reprends. Il y a trois solutions pour faire la même chose, dans une grande partie des cas :
- mysql_query() puis mysql_num_rows()
- mysql_unbuffered_query() avec la même requête que ci-dessus incluant une colonne COUNT() et, par conséquent, un GROUP BY
- mysql_unbuffered_query() pour récupérer les données puis un autre mysql_unbuffered_query() pour compter les tuples
Là, j'espère être clair.

Citation:

Envoyé par Kirkis

j'utilise les guillemets car, techniquement, les tuples ne sont pas exactement retournés

C'était une imprécision de ma part. Ils ne sont pas retournés "en mémoire" : ils sont retournés dans un socket, selon ce que tu as dit. J'aurais envie de faire une analogie avec une gestion de pointeurs...

Ok, donc pour la différence entre les deux fonctions _query(), il s'agit de choisir entre lire le socket et lire la mémoire (qui est une copie du socket en ce cas). Je n'avais pas vu les choses de ce point de vue mais cela se tient.

Ma journée se termine, je ne sais pas si je pourrai revenir avant lundi (et c'est bien triste).
Merci bien pour la discussion, en tout cas.
03/02/2006, 14h41
Kioob

Citation:

mysql_unbuffered_query() avec la même requête que ci-dessus incluant une colonne COUNT() et, par conséquent, un GROUP BY

rah... tu en veux à ce GROUP BY ! :wink: Je persiste : aucunement besoin, de cela.

Sinon, on est bien d'accord, il y a 3 méthodes classiques (on pourrait en fait ajouter le "select" classique, avec un compteur géré via PHP... pas tres sexy, mais dans certains cas, pourquoi pas).

Citation:

Ok, donc pour la différence entre les deux fonctions _query(), il s'agit de choisir entre lire le socket et lire la mémoire (qui est une copie du socket en ce cas). Je n'avais pas vu les choses de ce point de vue mais cela se tient.

Yep, et dans le cas d'un grand nombre de lignes retournées par la requète, la consommation mémoire peut avoir des effets desastreux sur les performances globales du serveur.

Citation:

Merci bien pour la discussion, en tout cas.

de même :)

Salut,

Si dans mon client mysql je fais :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 mysql> select * from classement; +---------+-----+ | nom | pts | +---------+-----+ | pierre | 10 | | paul | 10 | | jacques | 10 | | jean | 10 | | marie | 0 | +---------+-----+ 5 rows in set (0.01 sec) mysql>
Le 5 rows en 0.01 secondes, c'est qui qui le fourni ? le client mysql ou le serveur ? pareil pour la durée 0.01 sec ?

03/02/2006, 15h09
Kioob

Mr N : je n'en suis pas sûr à 100%, mais pour moi c'est le client.

Mais si tu fais un UPDATE, le affected_rows c'est le serveur qui le renvoit.

Kioob, je pense que tu n'es pas loin des 100% :) :
Sachant que mysql_query appelle mysql_read_query_result =>

Citation:

Envoyé par libmysql/libmysql.c

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
int STDCALL mysql_read_query_result(MYSQL *mysql)
{
  ...
  ...
  if ((field_count= net_field_length(&pos)) == 0)
  {
    mysql->affected_rows= net_field_length_ll(&pos);
    ...
    ...
  }
  ...
  ...
  if (!(fields=read_rows(mysql,(MYSQL_FIELD*) 0,5)))
    DBUG_RETURN(-1);
  ...
  ...
}
...
...
static MYSQL_DATA *read_rows(MYSQL *mysql,MYSQL_FIELD *mysql_fields,
                             uint fields)
{
  ...
  ...
  MYSQL_DATA *result;
  ...
  ...
  if (!(result=(MYSQL_DATA*) my_malloc(sizeof(MYSQL_DATA),
                                       MYF(MY_WME | MY_ZEROFILL))))
  ...
  ...
  result->rows=0;
  ...
  ...
 
  while (*(cp=net->read_pos) != 254 || pkt_len != 1)
  {
    result->rows++;
    ...
    ...
  }
  ...
  ...
}

Ce que je lis dans cet extrait de code :
- affected_rows est donné par le serveur
- num_rows est construit "à la volée" lors de la récupération des lignes;

CQFD

03/02/2006, 16h10
Kioob

ah, bah merci pour ces précisions ;)
03/02/2006, 18h42
Yogui
@Kioob

Essaie une requête de ce type sans mettre de GROUP BY, pour voir :
Code:

1 2 SELECT `username`, COUNT(*) AS `nb_of_users` FROM `phpbb_users`;
Si ça passe, tu m'appelles et on en rediscute ? :p
03/02/2006, 18h51
Kioob
Kirkis : c'est bien ce que je disais, on ne parlait pas de la meme chose...

moi je te parle de ça :
Code:

1 2 SELECT COUNT(*) AS `nb_of_users` FROM `phpbb_users`;
C'est à dire un comptage. Parce que 90% des personnes font des "SELECT *" suivi d'un mysql_num_rows() uniquement pour faire un comptage...
03/02/2006, 18h55
Yogui

C'est que j'étais dans l'idée de mettre le SELECT et le COUNT dans la même requête (cf. cas #2 dans mes exemples ci-dessus).

Je ne connaissais pas cette statistique, c'est peut-être pour cela que je m'obstinais à imposer mon COUNT et que tu ne me comprenais pas...

Bon, tout est réglé ? Nous n'avons pas dit trop de bêtises ?
03/02/2006, 18h57
Kioob

arf :)

disons que cette "statistique" sort tout droit de se forum :D

pour les bétises... bah... non... je crois pas, mis à part qu'on s'est pas mal répétés :P