gpt4 book ai didi

mysql - 在处理庞大的用户群时让迁移变得轻松

转载 作者:行者123 更新时间:2023-11-28 23:57:24 24 4
gpt4 key购买 nike

我想知道当您拥有庞大的用户群时,处理缓慢迁移的最佳方法是什么?

例如,我将用户的电子邮件列移动到 user_emails 表以允许用户发送多个电子邮件。所以,我有一个看起来像这样的迁移:

class MoveLegacyPrimaryEmailToUserEmails < ActiveRecord::Migration
def change
users = User.all
users.each do |user|
user_email = UserEmail.new
user_email.user_id = user.id
user_email.email = user.legacy_primary_email
user_email.save!
user.primary_user_email_id = user_email.id
user.save!
end
end
end

根据我所做的模拟,运行大约需要 66 分钟。为了加快速度并避免停机,我将其转换为原始 SQL 语句:

class MoveLegacyPrimaryEmailToUserEmails < ActiveRecord::Migration
def change
execute <<-SQL
INSERT INTO user_emails (email, user_id)
SELECT legacy_primary_email, id FROM users;
SQL
execute <<-SQL
UPDATE users
INNER JOIN user_emails
ON users.legacy_primary_email = user_emails.email
SET users.primary_user_email_id = user_emails.id;
SQL
end
end

这是处理这类问题的正确方法还是我遗漏了一些明显的东西?

最佳答案

我通常看到这个问题是通过多阶段部署来解决的:

  1. 如果可用,部署使用新数据库结构的代码,如果不可用,则回退到旧数据。
  2. 将数据迁移到新结构。
  3. 部署仅使用新数据结构的代码。
  4. 将旧结构迁移到遗忘中。

话虽如此,我不喜欢看护长达数小时的部署。如果您可以通过编写原始 SQL 来加快速度,那就去做吧。如果这使得它足够快,可以一步完成部署,那就太好了!

关于mysql - 在处理庞大的用户群时让迁移变得轻松,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31255658/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com