mysql - 在 Rails DB 迁移期间截断表是否有风险？

Question

我正在添加一个向 MySQL 表添加唯一索引的迁移。鉴于表中的现有数据可能不唯一，截断表中的任何现有数据以便添加唯一索引是否存在真正的风险？

值得一提的是，该应用程序仍在开发中，尚未发布到生产环境，因此我们不会丢失任何真实的用户数据。

有人能想出一个我们可能会丢失重要数据的现实场景吗？

迁移的代码示例:

class AddUniqueIndexToFooOnBarAndBaz < ActiveRecord::Migration
  def up
    ActiveRecord::Base.connection.execute("TRUNCATE foo")
    add_index :foo, [:bar_id, :baz_id], unique: true
  end

  def down
    remove_index :foo, [:bar_id, :baz_id]
  end
end

Answer 1

tl;dr-你不会真正伤害任何东西，但无论如何不要这样做。执行db:reset

当您编写迁移时，会发生以下情况:db/schema.rb 文件发生更改，并且其版本设置为上次运行的迁移的时间戳。迁移文件的存在是为了:

1. 您可以使用有意义的 DSL 拥有具体文件来演示数据库随时间的变化。
2. 如果您在开发过程中发现出现问题，您可以半任意地回滚对数据库的更改(不要回滚生产数据库，只需编写新的迁移)

这意味着迁移文件应该显示您正在对数据库执行的操作，并且 TRUNCATE 并不是您真正对数据库执行的操作，而是您对数据执行的操作。数据 。如果您使用已迁移的架构部署新环境，它不会破坏任何内容，并且 SQL 片段不会运行，但对于任何已经启动的环境，它都会运行。这有点奇怪，而且绝对没有必要。

详细信息

当您首次在环境中部署应用程序时，您(应该)运行 rake db:create db:schema:load db:seed 或 rake db:setup (它只是外包给其他命令)。 db:schema:load 只是将您的 schema.rb 文件转换为实际的数据库架构，其中包含表和索引以及所有有趣的东西。运行迁移后，您的架构文件将具有您想要的索引。然后，每当您部署到生产环境时，在添加任何数据之前，您的数据库都会像您希望的那样开箱即用。

在开发过程中，您不应该附加数据库中的任何数据 - 它是测试数据，不重要且短暂。将其全部清除应该不会感到难过，尤其是在因为现有数据可能无效/重复而进行截断的情况下。