数据库版本管理migration在有些场景下就是垃圾，是一坨屎。
直接上场景
1.keycloak这个开源的SSO组件，有10多年历史，有上千个migration迁移历史，很多表删了建，建了又删，然后10年前加了个字段，7年前又删了，索引增减，任何SQL操作都会记录历史做版本管理。本来只有几十个表的一个组件，有上千条DDL。
当 Liquibase（Keycloak 底层用的迁移工具）以极快的速度连续抛出成百上千个 DDL 时，数据库的元数据锁（Metadata Lock）竞争会瞬间飙升，导致死锁或超时。

我在很多场景遇到这种错，毫无办法，因为上千条DDL如洪水般涌来，性能稍差的服务器立马崩溃。
更大的问题是这种migration，量大，而且是代码级别，部署时遇到错误很难修改。我的做法是找一台高性能服务器，导出最后的全部数据和结构到一个SQL文件，原本需要5分钟的初始化，现在只需要30S，而且对服务器性能没有任何要求。

2.
Django 的 Migration 是基于有向无环图（DAG）的。
一旦多模块多人协作，加上持续开发升级，DAG就非常容易崩溃，报各种多个叶子节点或者顺序错误问题，然而实际上没有错误的，这个时候自带的makemigrations 也解决不了。也就是“依赖图（DAG）断裂”或“幽灵依赖”问题。
这种错误，干净环境是遇不到的，但是对于一个生产服务器升级，就非常容易遇上，极其难于解决。
最快最有效解决办法就是清空整个数据库，重新初始化应用，或者想尽办法骗过框架，或者就只能想办法妥协。

不是说migration一无是处，而是坑真的很恶心。