De flesta DBAPI-implementeringar buffrar helt rader när de hämtas - så vanligtvis, innan SQLAlchemy ORM ens får tag i ett resultat, finns hela resultatuppsättningen i minnet.
Men sedan, sättet Query fungerar är att den laddar den givna resultatuppsättningen helt som standard innan den returnerar dina objekt till dig. Skälet här gäller frågor som är mer än enkla SELECT-satser. Till exempel, i kopplingar till andra tabeller som kan returnera samma objektidentitet flera gånger i en resultatuppsättning (vanligt med ivrig laddning), måste hela uppsättningen rader finnas i minnet så att de korrekta resultaten kan returneras annars samlingar och liknande kanske bara är delvis befolkad.
Så Query erbjuder ett alternativ för att ändra detta beteende genom yield_per()
. Detta anrop kommer att orsaka Query för att ge rader i omgångar, där du ger den batchstorleken. Som dokumenten säger är detta bara lämpligt om du inte gör någon form av ivrig inläsning av samlingar så det är i princip om du verkligen vet vad du gör. Om de underliggande DBAPI-förbuffrarna rader, kommer det fortfarande att finnas minnesoverhead så att tillvägagångssättet bara skalas något bättre än att inte använda det.
Jag använder nästan aldrig yield_per(); istället använder jag en bättre version av LIMIT-metoden som du föreslår ovan med fönsterfunktioner. LIMIT och OFFSET har ett stort problem att mycket stora OFFSET-värden gör att frågan blir långsammare och långsammare, eftersom en OFFSET på N gör att den bläddrar genom N rader - det är som att göra samma fråga femtio gånger istället för en, varje gång man läser en större och större antal rader. Med ett tillvägagångssätt för fönsterfunktion hämtar jag i förväg en uppsättning "fönster"-värden som refererar till bitar av tabellen jag vill välja. Jag sänder sedan ut individuella SELECT-satser som var och en hämtar från ett av dessa fönster åt gången.
Fönsterfunktionsmetoden finns på wikin och jag använder den med stor framgång.
Observera också:inte alla databaser stöder fönsterfunktioner; du behöver Postgresql, Oracle eller SQL Server. IMHO använder minst Postgresql är definitivt värt det - om du använder en relationsdatabas kan du lika gärna använda den bästa.