表字段扩展方案
背景
业务需要，开发了新功能，对应的，需要对原表新增一些必要字段。想当然的
alter table add column
相信很多朋友和我一样，认为没问题。的确，针对一般的项目OK，为啥？因为数据量不大的小站当然没问题，alter造成的也是可以接受的。但是，针对数据量大且并发高的这肯定是有问题的。
于是，博主研究了一些成熟的应对方案。
解决方案
pt-online-schema-change
原理
以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
操作过程中需要注意：
- 变更过程中，最重要的是冲突的处理，一条原则，以触发器的新数据为准，这就要求被迁移的表必须有主键（这个要求基本都满足）
- 变更过程中，写操作需要建立触发器，所以如果原表已经有很多触发器，方案就不行（互联网大数据高并发的在线业务，一般都禁止使用触发器）
- 触发器的建立，会影响原表的性能，所以这个操作建议在流量低峰期进行
优点
整个过程不需要锁表，可以持续对外提供服务
建议
以上即为主流的大表新增字段的DBA解决方式，其实，更好的方案是设计表阶段就尽量规划好，有如下两种比较好的方案：
- 预留出足够的字段备用，“足够”怎么理解？需要一个熟悉业务的规划好。预留多了占用不少空间，预留少了也是没有意义，把握好度
- 可以采用“通用基础字段+version字段+ext字段”来设计表，通用基础字段即该表存储数据行的共性字段，ext字段是扩展字段，存储除了共性字段的其它个性字段的json字符串，verison字段用来标识ext代表的意义。注意，mysql此种方式ext中的字段不支持索引和查询（非要采用的话，需要特殊逻辑处理），MongoDB是支持的。
针对数据量不大，并发不高的可以采取简单的方式： - alter table add column
- 新增扩展表，用过联表查询来扩展（切记:大并发，大数据的不能用此方式，性能差劲）