表扩展方案

产品第一版：用户有用户名、密码、昵称等三个属性,对应表设计：
user(uid, name, passwd, nick)
第二版，产品经理增加了年龄，性别两个属性,表结构可能要变成：
user(uid, name, passwd, nick, age, sex)

在互联网企业业务发展初期，或者业务变更期，表字段增加非常频繁，且由于线上环境的库非常多，为了一个小小的需求增加一个字段非常痛苦，为了不影响业务，一般都会新建表-增加触发器-导数据-删除原表-重命名新表的方式。 一个数据库还好，但是线上的库一般都是成百上千的。

假设数据量和并发量比较大，怎么变？
（1）alter table add column？不太可行，锁表时间长
（2）新表+触发器？如果数据量太大，新表不一定装得下，何况触发器对数据库性能的影响比较高
（3）让dba来搞？新表，迁移数据，一致性校验，rename。

方案一：版本号+通用列
以上面的用户表为例，假设只有uid和name上有查询需求，表可以设计为
user(uid, name, version, ext)
（1）uid和name有查询需求，必须设计为单独的列并建立索引
（2）version是版本号字段，它对ext进行了版本解释
（3）ext采用可扩展的字符串协议载体，承载被查询的属性
优点：
（1）可以随时动态扩展属性
（2）新旧两种数据可以同时存在
（3）迁移数据方便，写个小程序将旧版本ext的改为新版本的ext，并修改version
不足：
（1）ext里的字段无法建立索引
（2）ext里的key值有大量冗余，建议key短一些
改进：
（1）如果ext里的属性有索引需求，可能Nosql的如MongoDB会更适合

方案二：通过扩展行的方式来扩展属性
以上面的用户表为例，可以设计为
user(uid, key, value)
优点：
（1）可以随时动态扩展属性
（2）新旧两种数据可以同时存在
（3）迁移数据方便，写个小程序可以将新增的属性加上
（4）各个属性上都可以查询
不足：
（1）key值有大量冗余，建议key短一些
（2）本来一条记录很多属性，会变成多条记录，行数会增加很多

方案三：
（1）提前预留一些reserved字段
这个是可以的。但如果预留过多，会造成空间浪费，预留过少，不一定达得到扩展效果。

方案四：
（2）通过增加表的方式扩展列，上游通过service来屏蔽底层的细节

一、哪些方案一定是不行的
（1）alter table add column
要坚持这个方案的，也不多解释了，大数据高并发情况下，一定不可行

（2）通过增加表的方式扩展，通过外键join来查询
大数据高并发情况下，join性能较差，一定不可行

（3）通过增加表的方式扩展，通过视图来对外
一定不可行。大数据高并发情况下，互联网不怎么使用视图。