存储过程遍历亿级大表查询结果的最优性能实现方案选型

首先明确前提：所有主流关系型数据库（MySQL、Oracle、PostgreSQL、SQL Server）中，你提到的FOR IN循环本质是数据库自动管理的隐式游标，和手动声明的普通显式cursor没有底层执行逻辑的差异，两者默认配置下都是逐行拉取数据，性能基本持平，完全不适合直接用来遍历1亿条规模的大表。

各方案性能梯队（从最高效到最低效排序） #

• 最优方案：基于有序索引键的分块批量处理
  这是亿级以上大表遍历的生产标准方案，性能是普通逐行游标的10~100倍。
  实现逻辑：以表的主键、自增ID或其他有连续有序索引的字段作为切分依据，每次固定拉取1000~10000条记录（块大小根据单条记录长度调整，单块总大小控制在1MB以内最优），比如用id BETWEEN start_id AND end_id的范围查询拉取一批数据，在内存中完成这批数据的业务处理后，再更新切分位点拉下一批。全程不持有长事务、不会持续占用数据库连接缓存、不会锁表，中途中断也可以从上次的位点续跑。
  注意：绝对不要用OFFSET xxx LIMIT xxx的方式做分页遍历，偏移量超过百万级后性能会指数级下跌。
• 次优方案：开启批量抓取配置的显式游标
  如果业务强制要求用游标实现，不要用默认逐行fetch的配置，要手动开启游标批量拉取参数：比如Oracle用BULK COLLECT指定批量抓取行数、PostgreSQL用FETCH FORWARD 块数量、SQL Server声明FAST_FORWARD READ_ONLY类型游标，一次从存储引擎拉取多行到SQL层缓存，大幅减少存储引擎和SQL层的上下文交互次数，性能比默认逐行游标高5~20倍。
• 最差方案：默认配置的FOR IN隐式游标、普通显式游标
  这两类实现性能几乎没有差异，FOR IN只是帮你自动完成了游标的声明、打开、遍历、关闭、异常回收的流程，底层还是逐行和存储引擎交互取数。1亿行的遍历场景下，单是上下文交互的开销就会占满CPU核心，跑数小时都无法完成，还极易触发事务日志膨胀、长事务锁表、连接内存溢出等故障，生产环境禁止直接使用。

关键提醒 #

亿级数据规模下，优先把业务逻辑转化为集合类SQL运算，不要做逐行遍历——集合运算的执行效率是逐行遍历的百倍以上。如果业务逻辑确实复杂到无法用SQL集合实现，不要把逻辑堆在存储过程里，建议按分片把数据同步到下游计算层处理，避免占用数据库核心实例的资源影响线上业务。

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