摘 要：本文阐述了MySQL DDL 的问题现状、pt-online-schema-change的工作原理，并实际利用pt-online-schema-change工具在线修改生产环境下1.6亿级数据表结构。
在一个软件生命周期中，我们都知道，前期的表结构设计是非常重要的，因为当表数据量一上来后再进行表结构修改危险性比较大，而且要操作的时间也比较长。
在笔者参与的项目中，就曾遇到这样一个问题，首先上去查看了一下该表的信息，已有约2亿的数据量，而且每分钟还要并发写入4万条记录，而由于这个表有一个字段前期设计过短，导致写入到数据库后，这个字段的值就一直乱码。因为该表在生产环境下使用，影响到业务，需要及时修改这个字段长度，并且修改该表结构时不能停服务。那么如何解决这种问题呢？
一、MySQL DDL 的问题现状
开始想了下，减少这个表的数据量再DDL,将这个表一周以前的数据备份到一个临时表，再删除这个表一周以前的数据。
而在MySQL中在对表进行ddl时，会锁表，当表比较小比如小于1w条记录时，操作时间较短，对前端影响较小，当时遇到千万乃至上亿级级别的表（保留一周的数据量还有1.6亿），就会影响前端应用对表的写操作。
因为目前InnoDB引擎是通过以下步骤来进行DDL的：
1 按照原始表（original_table）的表结构和DDL语句，新建一个不可见的临时表（tmp_table）
2 在原表上加write lock，阻塞所有更新操作（insert、delete、update等）
3 执行insert into tmp_table select * from original_table
4 rename original_table和tmp_table，最后drop original_table
5 释放 write lock。
我们可以看见在InnoDB执行DDL的时候，原表是只能读不能写的。为此 perconal 推出一个工具 pt-online-schema-change ，其特点是修改过程中不会造成读写阻塞。
二、pt-online-schema-change介绍
【工具简介】
pt-osc模仿MySQL内部的改表方式进行改表，但整个改表过程是通过对原始表的拷贝来完成的，即在改表过程中原始表不会被锁定，并不影响对该表的读写操作。
首先，osc创建与原始表相同的不包含数据的新表并按照需求进行表结构的修改，然后将原始表中的数据按chunk大小逐步拷贝到新表中，当拷贝完成后，会自动同时修改原始表和新表的名字并默认将原始表删除
【工具安装及使用】
参见下面下面这篇文章
linux下percona-toolkit工具包的安装和使用（超详细版）
【工作原理】
1 创建两个和你要执行 alter 操作的表结构一样的空表。如图：
说明：t_ad_req_log就是原表；
_t_ad_req_log_ol是旧表，这个表是用来当你执行失败的时候，还原回来的原表结构；
_t_ad_req_log_new是新表，这个表就是这次要修改的表。
2 执行表结构修改，然后从原表中的数据到copy到 表结构修改后的表（即_t_ad_req_log_new）
3 在原表上创建触发器将 copy 数据的过程中，在原表的更新操作更新到新表.
注意:如果表中已经定义了触发器这个工具就不能工作了。
4 copy 完成以后，用rename table 新表代替原表，默认删除原表。
修改的命令如下：
/usr/local/bin/pt-online-schema-change --user=用户名 --password=密码 --host=127.0.0.1 --port=端口号 --charset=utf8 --nodrop-old-table --alter="modify media_code varchar(64) DEFAULT NULL COMMENT '当前视频编码' " D=ad_api,t=t_ad_req_log --exec
参数说明：
--user=用户名 指定用户名
--password=用户名 指定用户密码
--port=端口号 指定端口号
--charset=utf8 指定字符编码
--alter= 后面就是接需要修改的内容，比如上面表示的就是修改ad_api数据库t_ad_req_log表的media_code 字段长度为64位
下面请看一个完整的图：
注：如果对percona-toolkit工具安装及使用有疑问的先查看下这两篇文章。
linux下percona-toolkit工具包的安装和使用（超详细版）