Discussion :

[darKnight94]

Bonjour à tous,

J'ai une requête mais qui va rechercher un trop gros nombre de rows, du coup une fatal erreur "out of memory" est généré.
Alors j'ai pu longtemps effectuer des recherches sur la toile et la plupart des conseils sont de modifier le php.ini ou autre modifications de limit mémoire mais ce n'est pas la méthode que je voudrai.
Pour ma part j'aurai plus pensez de deviser la requête, c'est à dire une requête dans une boucle while avec un offset départ 0 et limite 1000 qui s'auto-incrémenterai (offset = limit && limit = limit + 1000), mais quel serait la condition de sortie??? peut être en ajax.

Merci pour ceux qui veulent participer à ce brainstorming avec moi !!!!

[sabotage]

On peut peut-être déjà reflechir à la raison qui fait que cette requête est si longue a executer.

[darKnight94]

C'est une requête SELECT pour extraire des users d'une table selon des critères de recherche donc si je souhaite tout les users homme il doit y avoir des milliers de lignes du coup fatal error !!!

[sabotage]

Qu'est ce que tu fais de ces données ensuite ?
Tu les mets dans un tableau PHP ?

Parce que de toute façon ce n'est pas la requête qui utilise de la mémoire mais bien la quantité totale de données arrivant dans PHP ; donc tu auras pu segmenter la requête, quand tu rassembleras le resultat, ça sera toujours trop gros.

[darKnight94]

Code sql :

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

SELECT DISTINCT * FROM users WHERE user.user_civilite IN ('Monsieur');

Ma requête passe quand ma clause WHERE a plus de conditions ou quand ma requête a une LIMIT.

[Bovino]

Pourquoi mettre un IN quand tu n'as qu'une valeur à tester ?

[darKnight94]

oui désolé mais je met le IN quand y a plusieurs valeur (homme, femme, les deux à la fois), donc après j'affiche le résultat dans une table HTML ou un export excel via PHPExcel, donc si je comprend bien, c'est pas la requête qui génère l'erreur mais le remplissage dans la table ???

[Bovino]

Heu... j'ai rien contre les transgenre (du moins, j'aurais surtout pas le droit de le dire si c'était le cas ) mais si tu veux tester les deux, à priori c'est que tu n'as pas réellement besoin du WHERE...

[darKnight94]

non dans la table users au champs SEXE il y a NON RENSEIGNE, HOMME, FEMME, HOMME OU FEMME (pourquoi homme ou femme euhhh )

[sabotage]

Oui enfin même si ta requête retourne 50000 lignes cela n'explique pas que tu dépasses la mémoire.
A moins que
- ton serveur ait une limite mémoire très basse
- tu fasses des traitement fous sur les données après la requête

[darKnight94]

Ba non je fait rien de grandiose !!! j'ai vu qu'on pouvais faire des tables indexé, 100 rows dans la table avec des boutons pour afficher une autre page avec les 100 suivant ect ... peut être la solution non ???

[Celira]

Dans le cas d'un affichage HTML, oui, un affichage paginé serait sans doute une bonne idée (tu imagines ton utilisateur qui se retrouve face à un tableau de 15000 lignes dans une seule page )
A lire sur le sujet : Créer un système de pagination automatique en PHP (exemple sur un livre d'or !)

Dans le cas d'un export via PHPExcel, c'est un autre problème : il te faudra toutes les lignes. Toutefois, il doit être possible de générer le fichier par paquets ou quelque chose du genre. En tout cas, ce qui est sûr c'est qu'il ne faut pas récupérer toutes les données dans un tableau PHP et ensuite parcourir le tableau pour créer l'Excel

[Dendrite]

Ba non je fait rien de grandiose !!! j'ai vu qu'on pouvais faire des tables indexé, 100 rows dans la table avec des boutons pour afficher une autre page avec les 100 suivant ect ... peut être la solution non ???

En parlant d'index, tu en as posé sur ta table users dans ta base de données ? et lesquels ? une clé primaire, une clé d'unicité, un simple index sur le sexe ? (hihi ça me fait penser à la blague "Le pape a mis la capote à l'index, quelle drôle de façon de mettre une capote").

http://dev.mysql.com/doc/refman/5.7/...l-indexes.html