如何安全的大数据量表在线进行DDL操作

本文为博主原创，转载请注明出处

　　随着业务的需要，工作中需要对生产数据库的一些表做一些DDL操作，由于生产数据库表的数据量都是几千万，

而且生产数据库的表还在不断的进行新增和查询操作。应用中需要对生产数据库的表添加一个字段，由于考虑到数据量

大，而且表数据还在不断新增，以及进行查询等操作，为了不影响业务和数据，需要考虑在生产数据表添加字段时，不影响

正常业务，即不锁表也尽量减少性能的影响，所以通过不断查找，了解到使用以下的方式可以达到上面的效果，

ALGORITHM=INPLACE, LOCK=NONE;

　　来解释下：

Algorithm=Inplace ：可避免表拷贝导致的实例性能问题（空间、I/O问题），建议在 DDL 中包含该选项。

　　如果 DDL 操作不支持 Algorithm=Inplace 方式，DDL 操作会立刻返回错误。

Lock=None ：为了在 DDL 操作过程中不影响业务的 DML 操作，建议在 DDL 中包含该选项。

　　如果 DDL 操作不支持 Lock=None （允许并行 DML 操作）选项，DDL  操作会立刻返回错误。

默认情况下 MySQL 会尽量使用 algorithm=inplace , lock=none 来进行 DDL 操作。因此默认可以不指定这两个选项。

为了保障期间，还是在ddl中加上了上面的两个配置，一张两千万的表加一个字段执行了8分钟，正常新增。

SQL语句如下：

ALTER TABLE `fucdn_customer_domain_flow12` ADD COLUMN `total` int(11) NOT NULL COMMENT '请求数', ALGORITHM=INPLACE, LOCK=NONE;

2020.01.07--后续补充

　　昨晚系统上线发布，需要执行sql脚本，但刚点击sql脚本执行的时候，就返回下列错误：

当时就很惊讶，为什么一个alter table 增加字段的的sql执行会报一个主键冲突的异常，立马惊起一身冷汗。找到当晚mysql数据库值班的同事，

请教了一下，他一看便说这是  mysql版本为5.7中 alter table 的bug，他说我执行的sql需要加上 algorithm=copy 这个参数，当我具体请教这个是什么原因或

什么场景会导致异常时，大佬也是不能具体形容，只是说是mysql的bug，需要对sql加一个algorithm=copy 的保护就可以解决问题。后来再网上查询，看到一篇很好的文章

在此记录：

MySQL Online DDL的改进与应用（https://www.cnblogs.com/xinysu/p/6732646.html）

online DDL特性可以使很多ALTER TABLE操作避免表的复制，以及在DDL执行过程中对DML操作的阻塞。

它具有下面的优点：

在繁忙的生产系统中，当你修改索引或字段定义的时候，你可能会让一张表再几分钟内不可用，这个特性提高了数据库的响应速度和高可用性。