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

[cinlen]

假设有 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 ？想要各位后端大佬们的一些好的实践方案。

[sagaxu]

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

[zakokun]

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

[EricXuu]

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

[JYii]

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

[cinlen]

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

[billzhuang]

postgres 几乎没有这个问题。

[0x663]

@sagaxu DBA 是怎么做到的？

[sagaxu]

@0x663 DBA 字段加新表上，同步复制完数据，旧表只读改名，再把新表 rename 成旧表

[xuelu520]

不走 migrate 。
加入大表加字段什么的操作，锁表好久呢，这种肯定要闲时半夜去执行的。
另外有些字段是要先上线的，不好控制时间。

[ilucio]

dba 操作就没事了，rename 的时候找一个

[ilucio]

@ilucio 上面这个没打完就自动发了，重发一次。。

[ilucio]

@ilucio 生产上 drop column 风险很高，多余字段放着就好了，一般只有 DDL 无法更改字段类型时才需要考虑拉 DBA
rename 表

[Tidusy]

我这边刚出了一个线上故障。新增字段设置了默认值，上线后 auto-migrate 直接往存量数据刷数，把数据库卡了

[cinlen]

@Tidusy 如果项目中采用 migrate 的方式，那么如何避免这类情形发生呢？让 DBA review 吗？

[kivmi]

mysql> alter table sbtest1 add column create_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', algorithm=instant;
Query OK, 0 rows affected (0.02 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> alter table sbtest1 add column update_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间' ,algorithm=inplace;
Query OK, 0 rows affected (1 min 16.38 sec)
Records: 0 Duplicates: 0 Warnings: 0

这是 1000w 的表两种算法 DDL 修改的效果，而 algorithm=instant 是 mysql8.0 默认的算法，algorithm=inplace 是 mysql5.7 默认的算法，也就是说对于 mysql8.0 来说，并不需要 rebuild 数据表。

[dayeye2006199]

你们公司还有 dba ？？