请教后端们: 数据库 schema 变更让项目执行 migrate 还是让 DBA 处理？

假设有 user 微服务和 user 表.

user 微服务新增了一个迭代 v1.0.2 ，但是有一个 break change ，需要：

1. user 表新增一个字段 aaa
2. aaa 字段需要根据每个 user 的情况赋予不同初始值
3. user 表删除一个字段 bbb

目前有两种方案：

1. user 微服务 v1.0.2 上线后去 migrate user1.0.2.sql
2. 让 dba 在上线时配合去执行这些操作

这里只是举一个例子。

方案 1 感觉用的不少，但个人感觉线上 ddl 还是选择方案 2 dba 处理更稳妥一点, 特别是数据量大时涉及到锁表啥的。

请问什么情况下使用方案 1 ，什么情况下使用方案 2 ？想要各位后端大佬们的一些好的实践方案。

大表加个字段可能要锁表几个小时，DBA 处理可以缩短到秒级

删除字段这个行为没必要，线上业务从来不应该删除字段；即使要删除，那也是稳定运行了 N 个版本以后，确认没影响了才删除，谁会一上线就急匆匆的删除字段啊 只要不删除字段，那就是正常发布就行了，先加字段，然后发新版本，没啥特别的

先找 dba 加字段赋默认值，然后起一个刷数服务刷数。 删除字段不必要。确实要删，先去掉代码里的引用，稳定几个版本后删字段。

通常 DDL 操作都要走 OA 审批，到 DBA 去操作。 一个点是让开发操作少一点风险；另外一点数据库分配给 web 服务的权限不足，没法操作。 当然你要说你有权限，那应该默认你可以随便搞

@JYii 权限问题确实没考虑到，那确实无脑使用第二种方案就行了。

postgres 几乎没有这个问题。

@sagaxu DBA 是怎么做到的？