1. 需求
产品第一版：用户有用户名、密码、昵称等三个属性,对应表设计：
user(uid, name, passwd, nick)
第二版，产品经理增加了年龄，性别两个属性,表结构可能要变成：
user(uid, name, passwd, nick, age, sex)
假设数据量和并发量比较大，怎么变？
（1）alter table add column？不太可行，锁表时间长
（2）新表+触发器？如果数据量太大，新表不一定装得下，何况触发器对数据库性能的影响比较高
（3）让dba来搞？新表，迁移数据，一致性校验，rename？dba真苦逼
2. 版本号 + 通用列
以上面的用户表为例，假设只有uid和name上有查询需求，表可以设计为
user(uid, name, version, ext)
（1）uid和name有查询需求，必须设计为单独的列并建立索引
（2）version是版本号字段，它对ext进行了版本解释
（3）ext采用可扩展的字符串协议载体，承载被查询的属性
例如，最开始上线的时候，版本为0，此时只有passwd和nick两个属性，那么数据为：
| uid | name | version | ext |
| 1 | 张三 | 0 | {"passwd":"123","nick":NULL} |
| 2 | 李四 | 0 | {"passwd":"456","nick":"lisi"} |
当产品经理需要扩展属性时，新数据将版本变为1，此时新增了age和sex两个数据，数据变为：
| uid | name | version | ext |
| 1 | 张三 | 0 | {"passwd":"123","nick":NULL} |
| 2 | 李四 | 0 | {"passwd":"123","nick":"lisi"} |
| 3 | 王五 | 1 | {"passwd":"789","nick":NULL,"age":18,"sex":"F"} |
优点：
（1）可以随时动态扩展属性
（2）新旧两种数据可以同时存在
（3）迁移数据方便，写个小程序将旧版本ext的改为新版本的ext，并修改version
不足：
（1）ext里的字段无法建立索引
（2）ext里的key值有大量冗余，建议key短一些
改进：
（1）如果ext里的属性有索引需求，可能Nosql的如MongoDB会更适合
3. 通过扩展行的方式来扩展属性
以上面的用户表为例，可以设计为
user(uid, key, value)
初期有name, passwd, nick三个属性，那么数据为：
| uid | key | value |
| 1 | name | 张三 |
| 1 | passwd | 123 |
| 1 | nick | NULL |
| 2 | name | 李四 |
| 2 | passwd | 456 |
| 2 | nick | lisi |
未来扩展了age和sex两个属性，数据变为：
| uid | key | value |
| 1 | name | 张三 |
| 1 | passwd | 123 |
| 1 | nick | NULL |
| 2 | name | 李四 |
| 2 | passwd | 456 |
| 2 | nick | lisi |
| 3 | name | 王五 |
| 3 | passwd | 789 |
| 3 | nick | NULL |
| 3 | age | 18 |
| 3 | sex | F |
优点：
（1）可以随时动态扩展属性
（2）新旧两种数据可以同时存在
（3）迁移数据方便，写个小程序可以将新增的属性加上
（4）各个属性上都可以查询
不足：
（1）key值有大量冗余，建议key短一些
（2）本来一条记录很多属性，会变成多条记录，行数会增加很多
4. 在线表属性扩展方案
4.1 哪些方案一定是不行的
（1）alter table add column
-- 大数据量和大并发情况下，锁表时间太长
（2）通过增加表的方式扩展，通过外键join来查询
-- 大数据高并发情况下，join性能较差
（3）通过增加表的方式扩展，同视图来对外
-- 大数据高并发情况下，不推荐使用
4.2 在线表结构变更
新表 + 触发器 + 迁移数据 + rename（pt-online-schema-change），这是业内非常成熟的扩展列的方案。
以user(uid, name, passwd)扩展到user(uid, name, passwd, age, sex)为例
基本原理是：
（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）触发器的建立，会影响原表的性能，所以这个操作建议在流量低峰期进行