Het gebruik van setFirstResult en setMaxResults is de enige optie die ik ken.
Traditioneel zou een scrollbare resultatenset alleen rijen naar de client overbrengen als dat nodig is. Helaas maakt de MySQL Connector/J het eigenlijk nep, het voert de hele query uit en transporteert het naar de client, dus de driver heeft eigenlijk de hele resultatenset in RAM geladen en zal het naar je druppelen (bewezen door je geheugenproblemen) . Je had het juiste idee, het zijn gewoon tekortkomingen in het MySQL-java-stuurprogramma.
Ik vond geen manier om dit te omzeilen, dus ging ik met het laden van grote brokken met behulp van de reguliere setFirst/max-methoden. Sorry dat ik de brenger van slecht nieuws ben.
Zorg er wel voor dat u een staatloze sessie gebruikt, zodat er geen cache op sessieniveau of vuile tracking enz. is.
BEWERKEN:
Uw UPDATE 2 is de beste die u zult krijgen, tenzij u uit de MySQL J/Connector breekt. Hoewel er geen reden is om de limiet voor de query niet te verhogen. Op voorwaarde dat je genoeg RAM hebt om de index vast te houden, zou dit een wat goedkope operatie moeten zijn. Ik zou het een beetje aanpassen en een batch tegelijk pakken en de hoogste id van die batch gebruiken om de volgende batch te pakken.
Opmerking:dit werkt alleen als other_conditions gebruik gelijkheid (geen bereikvoorwaarden toegestaan) en gebruik de laatste kolom van de index als id .
select *
from person
where id > <max_id_of_last_batch> and <other_conditions>
order by id asc
limit <batch_size>