六个方案逐个排除，最后落在 pt-online-schema-change 的触发器五步原理
《数据库架构与实践》第 26 篇：MySQL 大表表结构平滑变更。
回答知识星球水友“逆光下的微笑”提问。
问题域：数据量大、并发量高场景，如何在流量低峰期，平滑实施表结构变更？
一般来说，是指增加表的属性，因为：（1）如果是减column，升级程序不使用即可；（2）如果是修改column，程序兼容性容易出问题；
首先，一起看下有哪些常见方案。
在线修改表结构
alter table add column
数据量大的情况下，锁表时间会较长，造成拒绝服务，一般不可行。
通过增加表的方式扩展属性，通过外键join来查询
举个例子，对：
t_user(uid, c1, c2, c3)
想要扩展属性，可以通过增加一个表实现：
t_user_ex(uid, c4, c5, c6)
数据量大的情况下，join性能较差，一般不可行。
通过增加表的方式扩展，通过视图来屏蔽底层复杂性
同上，视图效率较低，一般不使用视图。
揍产品经理，阻止她修改需求
…
提前预留一些reserved字段，加列可复用这些字段
这个方案可行，但如果预留过多，会造成空间浪费。
pt-online-schema-change
对于MySQL而言，这是目前比较成熟的方案，被广大公司所使用。
我呆过的互联网公司，数据库均使用MySQL。
下面仍以用户表扩展为例，说下这个工具内部的原理与步骤。
假设：
user(uid, name, passwd)
要扩展到：
user(uid, name, passwd, age, sex)
第一步，先创建一个扩充字段后的新表：
user_new(uid, name, passwd, age, sex)
就是被扩展后的表。
第二步，在原表user上创建三个触发器，对原表user进行的所有insert/delete/update操作，都会对新表user_new进行相同的操作；
第三步，分批将原表user中的数据insert到新表user_new，直至数据迁移完成；
第四步，删掉触发器，把原表移走（默认是drop掉）；
第五步，把新表user_new重命名（rename）成原表user；
扩充字段完成，整个过程不需要锁表，可以持续对外提供服务。
操作过程中需要注意：
（1）变更过程中，最重要的是冲突的处理，一条原则，以触发器的新数据为准，这就要求被迁移的表必须有主键（这个要求基本都满足）；
（2）变更过程中，写操作需要建立触发器，所以如果原表已经有很多触发器，方案就不行（互联网大数据高并发的在线业务，一般都禁止使用触发器）；
（3）触发器的建立，会影响原表的性能，所以这个操作必须在流量低峰期进行；
pt-online-schema-change是DBA必备的利器，比较成熟，在互联网公司使用广泛，要了解更详细的细节，亦可以Google一下。
任何脱离业务的架构设计都是耍流氓。
欢迎大家继续提问。
调研：贵司是如何扩展表结构的？
检验一下
检索练习 · 方案排除
文中前三个方案（在线 alter、外键 join、视图）被排除的原因分别是？
检索练习 · 五步原理
pt-online-schema-change 扩展字段的五个步骤是？
检索练习 · 冲突处理
pt-online-schema-change 变更过程中，冲突处理的一条原则是什么？对被迁移表有什么硬性要求？
检索练习 · 使用约束
哪两类情况会让 pt-online-schema-change 方案不可行或受限？
下一篇把数据量再拉满：1 万属性、100 亿数据、每秒 10 万吞吐的分类信息平台——第 27 篇《1 万属性、100 亿数据、10 万吞吐，架构怎么设计？》。
知其然，知其所以然。思路比结论更重要。