互联网应用会频繁加功能，修改需求。那么表结构也会经常修改，加字段，加索引。在线直接在生产环境的表中修改表结构,对用户使用网站是有影响。
以前我一直为这个问题头痛。当然那个时候不需要我来考虑,虽然我们没专门的dba，他们数据量比我们更大，那这种问题也会存在。
所以我很想看看业界是怎么做的,我想寻找有没有更高级的方案，呵呵，让我觉得每次开发一个新功能，我在线加字段都比较纠结。后来只知道，不清楚在什么时候，无意中看到一个资料介绍online-schema-change这个工具，于是顺便搜出了不少东西。
由于mysql在线ddl(加字段、加索引等修改表结构之类的操作）过程如下：
A.对表加锁(表此时只读)
B.复制原表物理结构
C.修改表的物理结构
D.把原表数据导入中间表中，数据同步完后，锁定中间表，并删除原表
E.rename中间表为原表
F.刷新数据字典，并释放锁
在这个过程中会锁表。造成当前操作的表无法写入数据，影响用户使用。由于需要复制原表的数据到中间表，所以表的数据量越大，等待的时候越长，卡死在那里(用户被拒绝执行update和insert操作,表现就是延迟了一直在等待)。
其实就是对表加了个排它锁，这个时候其他用户只能读表的数据,不能写。平时进行修改表的结构，更改字段，新增字段，更改字段名称一般都是通过ALTER TABLE TABLENAE 语法进行修改的。对于测试库，在线小表或者并发访问不是很大的情况是OK。但是如果是在线大表。那就很麻烦。由于表数据量大，复制表需要比较长的时间，在这个时间段里面，表是被加了锁的(写锁)，加写锁时其他用户只能select表不能update、insert表。表数据量越大，耗时越长。
所以，对于数据量大的表，数量很大。在线修改表结构一直是一个头痛的问题，因为互联网应用的一大特点不能影响用户正常使用，否则用户会慢慢流失掉。
有些公司碰到的表数据很小，几万到几十万行数据一张表，可能还不会遇到应用卡死的问题。所以我们网站在跑，开发个新功能，需要加个新字段,经常是直接操作不会影响什么(何况只是延迟写入操作而已,呵呵)