数据库迁移该不该用：先看它解决的问题是不是你的问题

MySQL 8.0.12 之后加列支持 INSTANT，只改元数据，千万行也是秒级

它擅长的是版本化的表结构变更；如果你只是多环境一致性，用现成的东西更省事。

先说结论

迁移的原则是「向前兼容、两步走」，能回滚的迁移比写得漂亮的迁移值钱

• 适合：版本化的表结构变更
• 不适合：灰度发布配套
• 学习成本：给大表加索引走 online DDL，但仍占 IO，业务高峰执行会拖慢查询
• 最大收益：DDL 拿不到 metadata lock 时会阻塞后续所有查询，排队几秒就能雪崩
• 最大风险：业务高峰跑大表 DDL，metadata lock 把整库拖死

它到底解决什么

MySQL 8.0.12 之后加列支持 INSTANT，只改元数据，千万行也是秒级。

换句话说，它把「版本化的表结构变更」这件事从手工变成可重复的流程。这是它真正的价值，而不是功能列表的长度。

什么时候不该用

下面三种情况，用了反而更累：

业务高峰跑大表 DDL，metadata lock 把整库拖死

迁移和代码同时上线，回滚时代码回了、库没回

迁移脚本里写死环境相关的库名，换环境就失败

和替代方案比

先删列再改代码，老版本代码还在写这一列，直接报错。

这台工具的关键细节

几个决定长期体验的点：

• 给大表加索引走 online DDL，但仍占 IO，业务高峰执行会拖慢查询
• DDL 拿不到 metadata lock 时会阻塞后续所有查询，排队几秒就能雪崩
• 先删列再改代码，老版本代码还在写这一列，直接报错
• 迁移脚本要幂等，重跑一次不能把数据插两遍

我的建议

迁移的原则是「向前兼容、两步走」，能回滚的迁移比写得漂亮的迁移值钱。

先用两周，跑一个真实的小任务；两周后你还想用它，再谈长期。

还有几处容易忽略的

都是小地方，但出问题时往往就卡在这里。

• 回滚脚本平时不测，真要用的时候基本都是错的

工具是解法，不是身份。