Ich habe einen grundlegenden Codesatz wie diesen (in einem Controller):

$sql = 'select * from someLargeTable limit 1000';
$em = $this->getDoctrine()->getManager();
$conn = $em->getConnection();
$statement = $conn->prepare($sql);
$statement->execute();

Meine Schwierigkeit besteht darin, dass die Speichernutzung nicht so schlecht ist, wenn die Ergebnismenge nur aus wenigen Datensätzen besteht. Ich habe einige Debugging-Informationen vor und nach dem Ausführen des @ wiederhol $ statement-> execute (); Teil des Codes und stellte für meine Implementierung fest, dass ich Folgendes habe:

pre-execute... rowCount :: 0 memory: 49.614 MB
post-execute... rowCount :: 1000 memory: 50.917 MB

Wenn dies von 1000 Datensätzen auf 10.000 erhöht wird, steigt der Unterschied in der MB-Nutzung auf 13 MB

pre-execute... rowCount :: 0 memory: 49.614 MB
post-execute... rowCount :: 10000 memory: 62.521 MB

Beim Abrufen von ca. 50.000 Datensätzen nähere ich mich meiner maximalen Speicherzuweisung:

pre-execute... rowCount :: 0 memory: 49.614 MB
post-execute... rowCount :: 50000 memory: 114.096 MB

Mit dieser Implementierung kann ich auf keinen Fall einen Controller (oder auch nur einen Befehl) schreiben, mit dem ich eine CSV-Datei mit Daten abrufen kann. Sicher, 50k + Einträge klingen sehr viel und die Frage wirft die Frage auf, warum, aber das ist nicht das Problem.

Meine letzte Frage lautet: Ist es möglich, der DBAL / Connection oder der DBAL / Statement mitzuteilen, dass sie bei der Ausführung die Daten innerhalb von SQL anstatt in PHP vollständig puffern sollen? Wenn ich zum Beispiel 10 Millionen Zeilen habe, um nur die ersten 10-KB-Zeilen an PHP zu senden, lassen Sie mich diese mit @ durchgehe@ statement-> fetch (); und wenn der Cursor das Ende der 10k erreicht, kürzen Sie das Array und holen Sie die nächsten 10k aus der DB?