如何在Rails中高效销毁数百万关联对象？

哥们，百万级关联销毁这个坑我踩过好几次！Rails默认的dependent: :destroy和delete_all在这种量级下完全扛不住，要么慢到离谱，要么把数据库锁死。给你分享几个生产环境验证过的方案，以及对应的工具：

默认方案的问题根源很明确：

• dependent: :destroy会触发每条记录的回调，还把所有操作包在一个超大事务里，百万级记录下事务会占满数据库连接，阻塞其他查询
• delete_all是单条SQL直接删，但会长时间锁表，同样影响业务

所以核心优化方向是异步化、分批处理、减少事务范围：

• 异步处理：把销毁任务丢到后台队列（比如Sidekiq、Active Job），不要在请求线程里执行，避免阻塞用户请求
• 分批销毁：把百万级记录拆成小批次（比如1000条/批），每批单独处理，降低数据库单次负载
• 缩小事务：要么每批用小事务，要么完全不包事务（业务允许的话），避免长时间占用数据库锁

如果你的业务必须保留Rails回调（比如销毁时要清理第三方资源、更新统计），这些Gem能帮你绕过默认的低效逻辑：

• batch_destroyer：专门为批量销毁设计，支持自定义批次大小、异步执行，能保留回调的同时避免大事务。可以直接替换默认的destroy_all，性能提升非常明显
• activerecord-import：虽然主打批量导入，但它的批量销毁扩展也很实用，能生成更高效的SQL语句，同时支持回调，比原生destroy_all快数倍
• sidekiq-batch：配合Sidekiq使用，把大销毁任务拆成多个小Job，还能监控任务进度、设置失败重试，适合需要跟踪销毁状态的场景

结合你的关联链（Users --> Projects --> Subscriptions/Notifications），分两种情况给出最优解：

情况1：不需要保留销毁回调（优先选这个！） #

如果Subscriptions和Notifications销毁时没有必须执行的业务逻辑，数据库级联删除是最快的方案，完全绕开Rails的低效关联处理：

1. 给关联表添加带级联删除的外键约束，写迁移文件：

   # 给Subscriptions添加Projects的级联删除外键
   add_foreign_key :subscriptions, :projects, on_delete: :cascade
   # 给Notifications添加Projects的级联删除外键
   add_foreign_key :notifications, :projects, on_delete: :cascade
   # 给Projects添加Users的级联删除外键
   add_foreign_key :projects, :users, on_delete: :cascade
   

2. 去掉所有模型里的dependent选项（比如User模型里的has_many :projects, dependent: :destroy要删掉）
3. 直接调用user.delete（不是destroy），数据库会自动级联删除所有关联的Projects、Subscriptions、Notifications，整个过程只需要几秒，完全不会阻塞业务

情况2：必须保留销毁回调 #

这种情况下只能异步分批处理，用Sidekiq写一个销毁Job：

class UserDestroyJob
  include Sidekiq::Job

  def perform(user_id)
    user = User.find(user_id)

    # 分批销毁每个Project下的关联记录
    user.projects.find_each do |project|
      # 分批销毁Notifications，保留回调
      project.notifications.find_in_batches(batch_size: 1000) do |batch|
        batch.each(&:destroy)
      end

      # 分批销毁Subscriptions，保留回调
      project.subscriptions.find_in_batches(batch_size: 1000) do |batch|
        batch.each(&:destroy)
      end

      # 销毁Project本身
      project.destroy
    end

    # 最后销毁User
    user.destroy
  end
end

然后在业务代码里调用UserDestroyJob.perform_async(user.id)，把销毁任务丢到后台执行。注意：

• 不要在Job里包大事务，每批销毁单独执行，降低数据库锁的持有时间
• 可以根据数据库负载调整批次大小（比如500或2000），找到性能和负载的平衡点
• 监控队列状态，避免Job堆积

临时应急方案（快速删除但跳过回调） #

如果需要紧急删除数据，又不想改数据库结构，可以用分批delete_all：

user.projects.find_each do |project|
  # 分批删除Notifications
  loop do
    deleted_count = project.notifications.limit(1000).delete_all
    break if deleted_count == 0
  end

  # 分批删除Subscriptions
  loop do
    deleted_count = project.subscriptions.limit(1000).delete_all
    break if deleted_count == 0
  end

  project.delete
end

user.delete

这个方案比一次性delete_all友好很多，每次只锁1000条记录，锁表时间极短，但同样会跳过所有回调，适合不需要业务逻辑的场景

• 操作前一定要备份数据！百万级数据删除不可逆
• 尽量在业务低峰期执行销毁任务，降低对线上业务的影响
• 监控数据库的CPU、IO和锁状态，避免出现性能瓶颈

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