PostgreSQL游标适用于大结果集处理，因其支持分批读取、服务端状态保存及减少锁表时间；典型场景包括大数据导出、后台批处理、流式API集成和前端分页；需注意事务绑定、避免长时间持有及合理设置fetch大小。
PostgreSQL 中的游标（Cursor）是一种数据库对象，允许用户在执行查询时逐步获取结果集中的数据，而不是一次性将所有数据加载到内存中。这种机制特别适合处理大结果集，避免因数据量过大导致内存溢出或性能下降。
为何游标适用于大结果集
当查询返回数百万甚至更多行数据时，如果直接使用常规 SELECT 查询，数据库驱动程序通常会尝试将整个结果集加载到客户端内存中。这不仅占用大量内存，还可能导致连接超时或程序崩溃。而使用游标可以：
- 分批读取数据：通过游标按需逐批获取数据，比如每次 fetch 1000 行，显著降低内存压力。
- 服务端保存状态：游标在数据库服务器端维护查询执行的状态和当前位置，客户端只需请求下一批数据。
- 避免长时间锁表：配合事务控制，可以在保证一致性的前提下，逐步处理数据，减少对表的锁定时间。
PostgreSQL 游标的应用场景
游标并非适用于所有查询，它主要用于以下几种典型场景：
- 大数据导出或迁移：需要将大量数据从数据库导出到文件或其他系统时，使用游标可实现流式输出，避免内存溢出。
- 后台批处理任务：例如每日数据清洗、统计汇总等作业，通过游标逐行或分块处理记录，提高稳定性和可控性。
- 与流式 API 或消息队列集成：在微服务架构中，可能需要将数据库记录一条条推送到 Kafka 或 RabbitMQ，游标支持这种“拉模式”数据供给。
- 前端分页展示超大数据集：虽然 Web 分页多用 LIMIT/OFFSET 或键集分页，但在某些后台管理界面中，也可用游标实现“上一页/下一页”的高效翻页。
使用注意事项
尽管游标有优势，但也有一些限制和最佳实践需要注意：
- 必须在事务中使用：PostgreSQL 的游标默认绑定到当前事务，一旦事务提交或回滚，游标即失效。若需跨事务访问，可考虑使用命名游标并显式控制生命周期。
- 避免长时间持有游标：长时间打开的游标会占用服务器资源，并可能阻止 VACUUM 回收死元组，影响性能。
- 合理设置 fetch 大小：fetch 过小会增加网络往返次数；过大则失去游标的意义。一般建议 1000~5000 行为一批。
- 注意并发行为：游标反映的是事务开始时的数据快照（基于事务隔离级别），不会看到其他事务在游标打开后提交的更改。
基本上就这些。对于大结果集的处理，PostgreSQL 游标提供了一种高效、可控的方式，尤其适合后台任务和数据管道场景。只要合理管理事务和 fetch 策略，就能在低资源消耗下稳定处理海量数据。
