L'utilisation de setFirstResult et setMaxResults est votre seule option à ma connaissance.
Traditionnellement, un jeu de résultats déroulant ne transférait les lignes au client que selon les besoins. Malheureusement, le connecteur MySQL/J le simule, il exécute l'intégralité de la requête et la transporte vers le client, de sorte que le pilote a en fait l'ensemble des résultats chargé dans la RAM et vous le transmettra (comme en témoignent vos problèmes de mémoire) . Vous avez eu la bonne idée, ce ne sont que des lacunes dans le pilote Java MySQL.
Je n'ai trouvé aucun moyen de contourner cela, alors j'ai chargé de gros morceaux en utilisant les méthodes setFirst/max habituelles. Désolé d'être porteur de mauvaises nouvelles.
Assurez-vous simplement d'utiliser une session sans état afin qu'il n'y ait pas de cache au niveau de la session ou de suivi sale, etc.
MODIFIER :
Votre mise à jour 2 est la meilleure que vous obtiendrez à moins que vous ne sortiez du MySQL J/Connector. Bien qu'il n'y ait aucune raison pour que vous ne puissiez pas augmenter la limite de la requête. À condition que vous disposiez de suffisamment de RAM pour contenir l'index, cela devrait être une opération peu coûteuse. Je le modifierais légèrement, et saisirais un lot à la fois, et utiliserais l'identifiant le plus élevé de ce lot pour saisir le lot suivant.
Remarque :cela ne fonctionnera que si other_conditions utiliser l'égalité (aucune condition de plage autorisée) et avoir la dernière colonne de l'index comme id .
select *
from person
where id > <max_id_of_last_batch> and <other_conditions>
order by id asc
limit <batch_size>
