Rails中调用PG::Result的find_in_batches方法报错，如何通过ActiveRecord方式批量查询rpush_notifications表数据？

我来帮你理清这个问题的根源，再给出两种实用的解决方案：

为什么你的初始查询会报错？ #

你用ActiveRecord::Base.connection.execute()执行SQL后，得到的是PostgreSQL驱动返回的PG::Result对象——这是一个底层的数据库结果集，而find_in_batches是ActiveRecord Relation（也就是Rails ORM构建的查询对象）才有的方法，底层结果集根本不支持这个方法，所以才会抛出undefined method 'find_in_batches'的错误。

方案一：不创建模型，手动实现批量查询 #

如果只是临时处理数据，不想新建模型，可以手动写分页逻辑来批量获取数据：

简单版：用OFFSET分页（适合小数据量） #

batch_size = 1000
offset = 0

loop do
  # 每次取1000条，偏移量逐步累加
  results = ActiveRecord::Base.connection.execute(
    "SELECT * FROM rpush_notifications WHERE error_code = 410 LIMIT #{batch_size} OFFSET #{offset}"
  )
  break if results.empty? # 没有数据就退出循环
  
  # 处理当前批次的每条数据
  results.each do |row|
    # row是哈希结构，比如可以用 row['id']、row['error_code'] 获取字段值
    # 这里写你的处理逻辑
  end
  
  offset += batch_size
end

注意：如果表的数据量很大，OFFSET会越来越慢，因为数据库需要先跳过前面所有的行才能取到目标数据。

高效版：基于主键分页（推荐大数据量场景） #

如果你的表有自增主键（比如id），用主键范围分页性能会好很多：

batch_size = 1000
last_id = 0

loop do
  # 只取id大于上一批最后一条的记录，按id排序后取1000条
  results = ActiveRecord::Base.connection.execute(
    "SELECT * FROM rpush_notifications WHERE error_code = 410 AND id > #{last_id} ORDER BY id LIMIT #{batch_size}"
  )
  break if results.empty?
  
  # 处理当前批次
  results.each do |row|
    # 你的处理逻辑
  end
  
  # 更新last_id为当前批次最后一条记录的id，下一批从这里开始
  last_id = results.last['id']
end

方案二：创建ActiveRecord模型（推荐长期使用） #

创建RpushNotification模型完全没问题，这是Rails操作数据库表的标准方式，能让你直接用ActiveRecord的各种便捷方法，代码更简洁安全。

第一步：创建模型文件 #

在app/models/rpush_notification.rb中添加以下代码：

class RpushNotification < ApplicationRecord
  # 如果表名和模型名的复数形式一致（rpush_notifications是RpushNotification的复数），这行可以省略
  self.table_name = 'rpush_notifications'
  
  # 如果你的表主键不是id，需要加上下面这行，替换成你的主键字段名
  # self.primary_key = 'custom_primary_key'
end

第二步：用模型实现批量查询 #

现在你就可以用你最初设想的方式来查询了，代码简洁又安全：

RpushNotification.where(error_code: 410).find_in_batches(batch_size: 1000) do |batch|
  # batch是RpushNotification实例的集合，直接调用属性方法即可
  batch.each do |notification|
    # 比如 notification.id、notification.error_code，不用再处理哈希
    # 你的处理逻辑
  end
end

这种方式还自带SQL注入防护（如果后续参数是动态的也不用担心），而且后续再操作这个表的话，直接用模型就能搞定，非常方便。

总结 #

• 临时处理数据：选手动批量查询快速解决；
• 长期需要操作这个表：创建模型是最优选择，符合Rails最佳实践。

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