生产数据库中的架构迁移？

Question

我已经开始学习web开发（具体来说是Flask和Django），在我看到的任何地方，数据库的主题总是从迁移开始。在

根据我对更新数据库的理解

1. 运行“something to generate migrate script”以生成一个迁移脚本，该脚本将使当前模型文件和当前数据库不同。在
2. 在本地数据库上测试迁移脚本。在
3. 提交迁移脚本，以便它到达您的生产环境，在生产环境中再次运行该脚本以更新您的生产数据库。在

但是当我从这个链接Schema Migration上阅读维基百科上的Schema Migrations时，我发现了以下文本：

schema migration is typically only used when the data held in the database is not real nor valuable, such as in software development, where developers work only with (possibly generated) test data.[citation needed] Programmatic schema migrations are almost never performed in production for the same reason.

它说在生产过程中应该避免迁移，那么您应该如何更新您的数据库？在

Answer 1

我相信作者的意思是自动化的模式迁移应该只在开发阶段、开发或测试环境中完成，因为在大型生产数据库上，模式迁移过程中可能会出现一些可用性或性能问题。在

例如，在MySQL5.6之前，没有本地的联机模式更改，所以在运行ALTER TABLE时，您必须有一个表锁。如果是一个小表，或者是一个包含生成数据的测试环境，这通常不是问题——一个小表会很快完成，您可以放弃一个测试表并重新生成数据——但生产环境中的一个大表可能会被锁定数小时，甚至数天或数周，从而导致系统无法进行任何与此相关的交互表。您必须采用替代的迁移方法来以最少的停机时间执行更改，而且自动化这些方法既不简单也不安全。在

Answer 2

我不知道维基百科文章的作者是从哪里得到这个想法的；根据历史，它已经是第一次修订了，对我来说，这种武断的限制没有意义。在

将数据库与程序版本一起迁移通常是必要的，这意味着对于生产数据库来说也是必要的。这里我不区分行中的数据和模式，因为这有点武断。从代码的角度来看，数据库是对数据进行编码的一种方式，编码方案直接影响到数据行中的模式和编码。在

也许讨论一下这种迁移的风险是有意义的（生产数据库有时包含诸如损坏的数据、通过手动运行SQL查询修改的数据）或复杂性（如添加和删除外键）的风险。但我见过很多产品在发布新版本时会迁移数据和模式。在

更新：我已经更新了维基百科页面，让我们看看编辑持续了多长时间：-）

Answer 3

是的，这太荒谬了。架构迁移一直在向生产数据库迁移。随着需求的变化，通常还需要改变底层数据库。Django和Flask都有执行数据库更新的路径，在当前版本中，Django是内置的mirgrate命令，在以前的版本中是South。Flask/SQLAlchemy有alembic来处理模式更改。尽管如此，这仍然是一个痛苦和危险的，所以测试测试并制定一个回滚计划。在