psycopg2中fetchmany与服务端命名游标差异及适用场景详解

两者的本质区别在于数据的存储位置和加载逻辑：

• 数据加载逻辑不同
  普通客户端游标调用fetchmany时，完整的查询结果集已经全部返回并存储在客户端的本地缓冲区中，fetchmany只是从本地内存里分批读取数据，不会再和服务端交互。就算你每次只拉10条，只要总结果集有1000万条，这1000万条数据已经全部占用了客户端内存。
  服务端命名游标是在PostgreSQL服务端持有查询上下文，结果集不会一次性计算完成也不会全部推送到客户端，每次拉取请求只会返回指定数量的数据，客户端仅需要存储当前批次的结果，内存占用只和单批大小有关。
• 事务依赖不同
  普通游标执行完查询后，你可以随时提交/回滚事务，后续调用fetchmany依然可以正常从本地缓冲区取数，不依赖服务端的事务状态。
  服务端游标绑定在当前事务中，一旦事务结束（提交/回滚），游标会直接失效，无法继续拉取数据，必须在同一个长事务内完成所有批次的拉取。
• 资源占用侧不同
  普通游标查询执行完成后，服务端的资源（内存、锁等）就会立即释放，只有客户端会占用结果集的内存。
  服务端游标会持续占用服务端的资源直到游标关闭或事务结束，如果持有时间过长，可能导致服务端内存占用过高、MVCC垃圾无法清理等问题，影响整个数据库实例的稳定性。
• 调用开销不同
  fetchmany是纯本地内存操作，没有额外开销，你可以随意调整每次拉取的批次大小，不会影响性能。
  服务端游标每次拉取都需要和服务端进行网络交互，批次太小会导致大量网络往返开销，批次太大则可能增加单次传输的延迟。

优先使用fetchmany（普通客户端游标）的场景 #

• 结果集总大小可控，全量加载到客户端内存不会造成OOM风险
• 业务要求查询完成后尽快提交事务，不允许持有长事务
• 对数据读取速度要求较高，希望尽量减少和服务端的交互次数

优先使用服务端命名游标的场景 #

• 结果集规模极大（百万级及以上），全量加载到客户端会直接导致内存溢出
• 数据处理逻辑耗时较长，不希望大量未处理的结果长期占用客户端内存
• 客户端运行环境内存受限，无法承载全量结果集的存储需求

常见误区：不要误以为单独使用fetchmany就能解决大查询的客户端OOM问题，普通游标模式下fetchmany只是本地分批读取，全量结果早就加载到客户端内存了，必须搭配服务端游标才能真正实现服务端分批拉取、降低客户端内存占用的效果。

内容的提问来源于stack exchange，提问作者Shiva