j'entend dire vite fait que SELECT * s'pa bien et que ça "rame". vrai ou pas?
les gens qui l'affirment preconisent plutôt le fait de stipuler TOUS les attributs (champs) UN PAR UN.    
 
quelqu'un est-il en mesure de dementir ou confirmer ces propos?    
 
 
l'argument principalement avancé serait que avec SELECT *, mysql serait obligé de rechercher et trouver lui-même le nom des champs.  

Je pense pas que ca lui prenne énormément de temps. A ce moment, il faudrait se demander le temps qu'il met à parser la liste des champs dans la requête  
 
Non, le problème, c'est sur les très grosses tables (beaucoup de colonnes), ou certains mettent SELECT * alors qu'ils n'ont besoin que de 2 champs  
Après, il peut aussi y avoir des problèmes si la table évolue (colonnes en plus)

oui le problème de SELECT * c'est que si tu as fait un mysql_fetch_array pour récupérer les données et que tu as ajouté des champs dans la table, t'es quasi sur de planter tes scripts

Comme mrbebert dit, le problème vient principalement du RecordSet que tu dois transmettre.
 
Imaginons une table de 20 champs, et que tu veuilles peupler un menu déroulant avec un seul de ces champs, et l'ID correspondant pour lui donner une valeur concrète.
Tu as besoin de 2 champs, c'est inutile de sélectionner toute la table, surtout si dans tes 20 champs tu en as un qui est un BLOB
 
Pour répondre à ta question, "ramer" est un bien grand mot, surtout sur les serveurs de nos jours. Mais tu risques d'observer une perte de performance sur des pages qui demandent beaucoup de Select...  
 
Quoi qu'il en soit, laisser des "Select *" (et, PIRE, des Count(*) !! ) dans une requête où tu n'as pas besoin de tous les champs et/ou qui concerne une table qui a des chances d'évoluer, c'est comme des vêtements troués : de manière moins performante, ça fonctionne et remplit son rôle, mais surtout c'est cochon.

ok merci a vous. c'est l'idee que je m'en faisait aussi, ça rejoint ce que j'en pensais.    
 
et sinon c'est quoi BLOB et le rapport qu'il joue avec SELECT?   J'ai l'impression d'avoir deja vu se terme sur PHPMyAdmin...

C'est un champ qui contient des données binaires, sans type particulier. Et, bien souvent, des données de taille importante (une image par exemple peut être enregistrée dans un champ BLOB)  
 
Zebix > c'est quoi le problème avec le COUNT(*)    
(je l'utilise super souvent )

Infos sur le BLOB en MySQL : http://dev.mysql.com/doc/mysql/en/blob.html
 

 
Pour un peu la même raison que le SELECT *...
 
Lorsque tu n'as besoin de savoir uniquement le nombre de champs retournés par une requête, sans restriction particulière sur les champs comptés c'est-à-dire compris dans le COUNT() (restriction définie par exemple par un HAVING en fin de requête), rien ne sert de jongler avec l'intégralité des données.  
 
Tu peux donc utiliser COUNT(1) à la place, le moteur ne comptera que la présence d'un tuple, sans se soucier le moins du mondre du contenu.
 
Je viens de faire quelques essais sur un serveur Linux assez performant (bi-Xeon, 2Gb ram, Mandrake 10.1 etc.) :  
 
J'ai fait un COUNT d'une requête qui croise deux tables assez volumineuses (plusieurs dizaines de Mb par table) et correctement indexées :
 
COUNT (1) : 507551 rows retournés en 0.32 sec.
COUNT (*) : 507551 rows retournés en 0.75 sec. (après avoir vidé le cache).
 
CQFD.

Merci, on en apprend tout les jours      
 
Pour moi, "COUNT(*)" indiquait justement que je voulais pas tenir compte du contenu des champs. Ce n'est donc pas le cas.
 
Ce que je comprends pas, c'est la différence qu'il y a entre les 2. COUNT(*) compterait uniquement les champs qui ont au moins 1 colonne non nulle