Bonjour à tous,
 
J'ai une petite question : je dois effectuer une requête pour récupérer 5000 enregistrements sur une base MySql via PHP, et dont je n'ai que les id, et je me demande ce qui serait le plus rapide...
 
- Faire un SELECT * FROM demande WHERE DEM_ID IN ( 104737, 400385, 400939, 400941, 401028.... )     où je mets tous mes 5000 id d'un coup, et je les traite tous d'un coup dans le PHP ( ce n'est pas un peu lourd ? )
- Faire un SELECT * FROM demande WHERE DEM_ID IN ( 104737, 400385, 400939, 400941, 401028.... )     mais là je mets les id par bloc de 100 id, et je les traitre par à coup, lançant donc 50 fois la requête.
- Faire un SELECT * FROM demande WHERE DEM_ID = 104737, et donc lancer la requête pour chaque id ( 5000 fois ).
 
La requête peut sembler évidente, mais le script me fait aussi des erreurs de segmentation par moment, donc je me demande si ça ne vient pas de là.
 
Merci d'avance !

fait des bench, avec la fonction time();

Sans doute déjà ne pas faire SELECT * mais bien noter un à un les champs qui t'intéressent uniquement. Ensuite, la 3e version est clairement inintéressante et beaucoup plus couteuse pour mysql.  
 
Pour ma part, je pencherai plutôt pour la première requête.

la premiere

1ère option définitive, après tu peux contruire l'ordre de tes resultats avec  
" when 400941 then 1 etc.."

D'où vienne ces 5000 id ? formulaire ? csv ?  
ne serait t'il pas plus rapide d'ecrire les 5000 id dans une table MEMORY ou TEMPORARY puis de faire une jointure ?
 
Tu peux aussi faire des EXPLAIN pour demander à mysql d'expliquer la requete que tu lui donne.?

C'est bien ce dont je me doutais un peu, c'est la première qui serait la mieux au niveau stabilité et rapidité...

En gros, le principe est le suivant : je réalise un export csv d'une table de demandes, cet export étant lancé par cron le soir à 00h30, et il est ensuite envoyé par mail au client.
Le fait est que les id que j'ai à envoyer chaque soir me sont fournis par une autre application propriétaire du client ( ni PHP, ni MySQL, vraiment aucun rapport ), et par bloc de 5000. Je prends ces id ( il peut y en avoir 0 ou 50000 au final), et je fais donc mes requêtes sur la base par bloc de 5000 demandes. Ainsi, si j'ai 15000 demandes à envoyer, je vais donc faire 3 envois de mails, chacun contenant un csv de 5000 demandes ( car le fichier csv a lui aussi du mal s'il contient plus de 5000 demandes ).
 
Globalement ça tournait bien pour le moment, mais j'avais des erreurs de segmentation, donc je suis en train d'alléger le code ( qui était assez lourd dans sa 1ère version ), et je me demandais donc si je pouvais gratter quelque chose du coté de MySQL...

Dépendant de la proportion de commandes / produits différents / produits stockés, ne serait-il pas plus efficace de lire l'ensemble de la base de données (en se limitant, bien entendu, aux attributs nécessaires) et de travailler avec une table de hachage pour rechercher les informations des produits ?

Bonjour,
 
Ensuite ça dépend comment tu construit ta base de données ! ( les table de paramétrage plutôt que les champs libre,... )
Est -ce que le client a besoin de recevoir les données par mail ? tu pourrais peut-être lui proposer de les lire directement sur le serveur et donc de les traiter directement dessus (économie des envois, des traitements de retour)

Heu.... table de hachage, c'est quoi ça ?  

Clairement il veut les recevoir par mails ( c'est son choix technique définitif )
 
 

Une association clé => valeur

Ok je vois    
Sinon au final, j'ai fait la requête sur les 5000 id d'un coup, et j'ai travaillé mon script pour l'optimiser au maximum ( une seule boucle de traitement, le moins possible de tests, les envois de mails se font d'un coup à la fin et pas petit à petit, etc ) afin d'améliorer les temps de traitements.
Le résultat est impressionnant : le script est presque 10 fois plus rapide et ne fait plus d'erreur de segmentation !    
 
En tout cas merci pour votre aide