Différence entre ...

et

:?:

Ces deux requêtes donnent le même résultat, mais laquelle est mieux que l'autre ?

Le count évidemment, le select * récupère des données inutilement

oki, sauf si j'ai besoin des éléments récupérés par après. Dans ce cas, je ferai d'une requête deux variables :-D

Je pense que tu peux même remplacer ton * par l'id de ta table pour gagner en performance.
Si qqun peut confirmer

Confirmé

complètement infirmé !!

http://www.mysqlperformanceblog.com/2007/04/10/count-vs-countcol/
http://www.rustyrazorblade.com/index.php/2007/01/19/count1-vs-count-any-difference/

Ez3kieL a dit:

Je pense que tu peux même remplacer ton * par l'id de ta table pour gagner en performance.
Si qqun peut confirmer

Cliquez pour agrandir...

Non, cela fera une projection en plus. Sans rentrer dans les détail, le moteur sql commence par prendre tous les champs en mémoire pour traiter le WHERE. Ensuite il va regarder le SELECT pour voir ce qu'il faut garder.

Autant pour moi, j'avais mal lu : je croyais qu'il parlait de l'id d'un champ de la table :roll:

Comme l'a dit Calvin il ne faut JAMAIS utiliser *, qu'importe la requete.

Avec un peu de bon sens, la méthode la plus économique

1) Effectuer une requête TRAITER par MySql qui renverra UNE réponse au serveur PHP. Commande SQL standard optimiser, qui plus est.
2) MySql renvoyant la totalité des ligne au serveur PHP, puis le serveur ayant récupéré l'ensemble des données stockées sous forme de tableau qui va utiliser une fonctionnalité PHP pour compter


Autant d'un point de vue mémoire ou de traitement, la réponse me semble inutile.

La Poubelle a dit:

Comme l'a dit Calvin il ne faut JAMAIS utiliser *, qu'importe la requete.

Cliquez pour agrandir...

C'est en fait le contraire qu'il dit : un count(*) est toujours plus rapide qu'un count(nom_d'un_champ). Maintenant dans le cas d'une requete select normale (ou on veut des lignes de la DB, et pas le nombre de ligne), il est effectivement préférable de récupérer juste les champs dont on a besoin plutot que tous (*), pour limiter le nombre de données transmises entre la DB et le serveur web. Mais même dans ce cas la, un "select * from ..." sera plus rapide qu'un "select champ1, champ2 from ...".

Tifox a dit:

C'est en fait le contraire qu'il dit : un count(*) est toujours plus rapide qu'un count(nom_d'un_champ). Maintenant dans le cas d'une requete select normale (ou on veut des lignes de la DB, et pas le nombre de ligne), il est effectivement préférable de récupérer juste les champs dont on a besoin plutot que tous (*), pour limiter le nombre de données transmises entre la DB et le serveur web. Mais même dans ce cas la, un "select * from ..." sera plus rapide qu'un "select champ1, champ2 from ...".

Cliquez pour agrandir...

Pas en SQLServer.

Les procédures stockées sont optimisées.

Je ne suis pas ultra-familier des procédures stockées, mais je ne vois pas très bien ou il y a une procédure stockée dans un select.

Note que ce n'est pas un reproche et que je peux certainement me tromper, j'aimerai juste en savoir plus la dessus.

La Poubelle a dit:

Pas en SQLServer.

Les procédures stockées sont optimisées.

Cliquez pour agrandir...

on ne parle pas du tout de procédure stockée là.
Tifox a très bien résumé.
un count(*) est en tout cas aussi rapide qu'un count(nom_champ)

et un select a,b,c,d est en tout cas aussi rapide qu'un select *.

Calvin80 a dit:

on ne parle pas du tout de procédure stockée là.
Tifox a très bien résumé.
un count(*) est en tout cas aussi rapide qu'un count(nom_champ)

et un select a,b,c,d est en tout cas aussi rapide qu'un select *.

Cliquez pour agrandir...

Testé sur une BDD avec une centaine de champs et quelques millions de records ainsi que la charge du serveur avec le parcours dans un logiciel ?

Le premier lien de calvin fait un test sur une table avec 7 million de record, et les quelques recherches que j'ai faites tantot au boulot avait l'air de confirmer ça je ferai quelques test sur les BD du boulot demain pour voir.

La Poubelle a dit:

Testé sur une BDD avec une centaine de champs et quelques millions de records ainsi que la charge du serveur avec le parcours dans un logiciel ?

Cliquez pour agrandir...

fait un explain d'un query, tu comprendras pkoi ça donne ce résulat !

Comme tu peux le constater sur ton premier lien, son test est ralenti à cause de l'exclusion des valeurs null.

Comme beaucoup, la fonction COUNT est utilisé avec l'ID est non avec un champ qui renverra des valeurs lourdes ou douteuses.


Dans un select classique, Sur une BDD d'une cinquante de champ (bien chargé en string, pour faire court). Entre "SELECT * FROM TBL" et "SELECT ID, CHAMP1 from TBL". Il est impossible que le serveur n'en prenne pas un coup au niveau de la charge et de la mémoire.

Ce n'est pas avec ce petit test à moitié fini qu'il faut faire une généralité sur les requêtes SQL avec *

Il ne faut pas oublier que le résultat est renvoyer au logiciel pour seulement être traité.

La Poubelle a dit:

Dans un select classique, Sur une BDD d'une cinquante de champ (bien chargé en string, pour faire court). Entre "SELECT * FROM TBL" et "SELECT ID, CHAMP1 from TBL". Il est impossible que le serveur n'en prenne pas un coup au niveau de la charge et de la mémoire.

Cliquez pour agrandir...

je ne te suis plus..
on ne compare pas select count(*) et select *, on compare select count(*) et select count(champ) et , d'un autre coté, select * et select champ1, champ2 etc...

temps_executiont(count *) <= temps_execution (count champ)
et
temps execution (select *) >= temps_execution (select champ1,champ2,...)

Heu non, on comparais mysql_num_rows à SELECT COUNT(*) d'abord ...

Notons que l'on peut faire SELECT champ_1, champ_2 COUNT(champ_3) FROM table WHERE ... d'après ce j'ai lu =]

SkYlEsS a dit:

Heu non, on comparais mysql_num_rows à SELECT COUNT(*) d'abord ...

Notons que l'on peut faire SELECT champ_1, champ_2 COUNT(champ_3) FROM table WHERE ... d'après ce j'ai lu =]

Cliquez pour agrandir...

oui, mais tu vas devoir faire un group by. =]