从表扩展增加列属性说起
需求背景
产品第一版，用户有用户名、密码、昵称等三个属性，对应表设计：
user(uid, name, passwd, nick)
产品第二版，产品经理增加了年龄，性别两个属性，表结构可能要变成：
user(uid, name, passwd, nick, age, sex)
讨论问题域
1）数据量大、并发量高场景，在线数据库属性扩展
2）数据库表结构扩展性设计
哪些方案一定不行
1、alter table add column
要坚持这个方案的，也不多解释了，大数据高并发情况下，一定不可行
2、通过增加表的方式扩展，通过外键join来查询
大数据高并发情况下，join性能较差，一定不可行
3、通过增加表的方式扩展，通过视图来对外
一定不可行。大数据高并发情况下，互联网不怎么使用视图
4、必须遵循“第x范式”的方案
一定不可行。互联网的主要矛盾之一是吞吐量，为了保证吞吐量甚至可能牺牲一些事务性和一致性，通过反范式的方式来确保吞吐量的设计是很常见的，例如：冗余数据。互联网的主要矛盾之二是可用性，为了保证可用性，常见的技术方案也是数据冗余。在互联网数据库架构设计中，第x范式真的没有这么重要
5、打产品经理
没试过...
哪些方案可行
1、提前预留一些reserved字段
方案可行，但如果预留过多，会造成空间浪费，预留过少，不一定达得到扩展效果。
2、通过增加表的方式扩展列，上游通过service来屏蔽底层的细节
方案可行，比如新增表UserExt(uid, newCol1, newCol2)（但join连表和视图是不行的）。
3、版本号+通用列
以上面的用户表为例，假设只有uid和name上有查询需求，表可以设计为
user(uid, name, version, ext)
（1）uid和name有查询需求，必须设计为单独的列并建立索引
（2）version是版本号字段，它对ext进行了版本解释
（3）ext采用可扩展的字符串协议载体，承载被查询的属性
例如，最开始上线的时候，版本为0，此时只有passwd和nick两个属性，那么数据为：
当产品经理需要扩展属性时，新数据将版本变为1，此时新增了age和sex两个数据，数据变为：
优点：
（1）可以随时动态扩展属性
（2）新旧两种数据可以同时存在
（3）迁移数据方便，写个小程序将旧版本ext的改为新版本的ext，并修改version
不足：
（1）ext里的字段无法建立索引
（2）ext里的key值有大量冗余，建议key短一些
改进：
（1）如果ext里的属性有索引需求，可能Nosql的如MongoDB会更适合
4、通过扩展行的方式来扩展属性
以上面的用户表为例，可以设计为
user(uid, key, value)
初期有name, passwd, nick三个属性，那么数据为：
未来扩展了age和sex两个属性，数据变为：
优点：
（1）可以随时动态扩展属性
（2）新旧两种数据可以同时存在
（3）迁移数据方便，写个小程序可以将新增的属性加上
（4）各个属性上都可以查询
不足：
（1）key值有大量冗余，建议key短一些
（2）本来一条记录很多属性，会变成多条记录，行数会增加很多
重点：在线表结构变更
对于在线表扩展，业内比较成熟的方案是 pt-online-schema-change，即新表 + 触发器 + 迁移数据 + rename。
我们知道MySQL默认 online ddl 的原理如下：
（1）创建一个和原来表结构一样的临时表并ddl
（2）锁住原表，所有数据都无法写入（insert,update,delete）
（3）将原表数据写入到临时表中（通过insert ...select方式）
（4）写入完后，重命名临时表和原表名称
（5）删除原表，释放锁
如果表非常大的话，以上的锁表时间之长是无法忍受的。
以user(uid, name, passwd)
扩展到user(uid, name, passwd, age, sex)为例
pt-online-schema-change 的原理如下：
（1）先创建一个扩充字段后的新表user_new(uid, name, passwd, age, sex)
（2）在原表user上创建三个触发器，对原表user进行的所有insert/delete/update操作，都会对新表user_new进行相同的操作
（3）分批将原表user中的数据insert到新表user_new，直至数据迁移完成
（4）删掉触发器，把原表移走（默认是drop掉）
（5）把新表user_new重命名（rename）成原表user
扩充字段完成。
优点：整个过程不需要锁表，可以持续对外提供服务
操作注意事项：
（1）变更过程中，最重要的是冲突的处理，一条原则，以触发器的新数据为准，这就要求被迁移的表必须有主键（这个要求基本都满足）
（2）变更过程中，写操作需要建立触发器，所以如果原表已经有很多触发器，方案就不行（互联网大数据高并发的在线业务，一般都禁止使用触发器）
（3）触发器的建立，会影响原表的性能，所以这个操作建议在流量低峰期进行
pt-online-schema-change 是DBA必备的利器，比较成熟，在互联网公司使用广泛。
