内存高效的内置SqlAlchemy迭代器/生成器？
我有一个〜10MloggingMySQL表，我使用SqlAlchemy接口。 我发现在这个表的大子集上查询会消耗太多的内存，即使我以为我使用了一个内置的生成器，可以智能地获取数据集的一小块数据块：
for thing in session.query(Things): analyze(thing) 为了避免这种情况，我发现我必须构build自己的迭代器，
lastThingID = None while True: things = query.filter(Thing.id < lastThingID).limit(querySize).all() if not rows or len(rows) == 0: break for thing in things: lastThingID = row.id analyze(thing)
这是正常的，还是有什么我错过有关SA内置发电机？
这个问题的答案似乎表明，内存消耗是不可预料的。
大多数DBAPI实现在获取行时充分缓冲行 – 通常，在SQLAlchemy ORM甚至获得一个结果之前，整个结果集在内存中。
但是，查询的工作方式是，在返回给对象之前，默认情况下会完全加载给定的结果集。 这里的基本原理是针对不仅仅是简单的SELECT语句的查询 – 连接到可能在一个结果集中多次返回相同的对象标识的其他表（在急切加载中通用），整套行需要在内存中可以返回正确的结果 – 否则集合等可能只是部分填充。
所以Query提供了一个选项来改变这种行为，即yield_per（）调用http://www.sqlalchemy.org/docs/orm/query.html?highlight=yield_per#sqlalchemy.orm.query.Query.yield_per 。 这个调用将导致查询产生成批的行，你给它的批量大小。 正如文档所述，这只有在您不需要加载任何集合的情况下才适用 – 所以基本上，如果您确实知道自己在做什么。 而且，如果底层的DBAPI预先caching了行，那么仍然会有这样的内存开销，所以这种方法只比没有使用它稍微好点。
我很less使用yield_per（） – 相反，我使用了上面使用窗口函数build议的LIMIT方法的更好的版本。 LIMIT和OFFSET有一个很大的问题，即非常大的OFFSET值导致查询变得越来越慢，因为N的OFFSET导致它遍历N行 – 这就像执行相同的查询50次而不是1次，每次读取越来越多的行。 使用窗口函数方法，我预先获取一组“窗口”值，这些值指向要select的表的块。 然后我发出单独的SELECT语句，每次从这些窗口中的一个拉一次。
窗口函数的方法是在维基上http://www.sqlalchemy.org/trac/wiki/UsageRecipes/WindowedRangeQuery ，我用它很成功。
另请注意，并非所有数据库都支持窗口function – 您需要PG，Oracle或SQL Server。 恕我直言，至less使用Postgresql绝对是值得的 – 如果你使用的是关系型数据库，那么最好使用它。
我一直在寻找与SQLAlchemy有效的遍历/分页，并希望更新这个答案。
我认为你可以使用slice调用来正确限制查询的范围，并且可以高效地重用它。
例：
window_size = 10 # or whatever limit you like window_idx = 0 while True: start,stop = window_size*window_idx, window_size*(window_idx+1) things = query.slice(start, stop).all() if things is None: break for thing in things: analyze(thing) if len(things) < window_size: break window_idx += 1
本着Joel的回答精神，我使用以下内容：
WINDOW_SIZE = 1000 def qgen(query): start = 0 while True: stop = start + WINDOW_SIZE things = query.slice(start, stop).all() if things is None: break for thing in things: yield(thing) start += WINDOW_SIZE
AFAIK，第一个变体仍然从表中获取所有元组（使用一个SQL查询），但是在迭代时为每个实体构buildORM表示。 所以它比迭代之前build立所有实体列表更有效率，但是你仍然需要将所有（原始）数据提取到内存中。
因此，在巨大的桌子上使用LIMIT听起来像是个好主意。
使用LIMIT / OFFSET是不好的，因为你需要先find所有的{OFFSET}列，所以更大的是OFFSET – 你得到的更长的请求。 对于我来说，使用窗口化查询也会在大型数据表（大量数据等待第一个结果的时间太长，对于分块的Web响应不太好）上给出不好的结果。
这里给出的最佳方法是https://stackoverflow.com/a/27169302/450103 。 在我的情况下，我解决了问题，只需使用date时间字段上的索引，并使用datetime> = previous_datetime获取下一个查询。 愚蠢的，因为我在之前的不同情况下使用该索引，但认为对于提取所有数据窗口查询会更好。 在我的情况下，我错了。
