一、哪些方案一定是不行的
（1）alter table add column
要坚持这个方案的，也不多解释了，大数据高并发情况下，一定不可行
（2）通过增加表的方式扩展，通过外键join来查询
大数据高并发情况下，join性能较差，一定不可行
（3）通过增加表的方式扩展，通过视图来对外
一定不可行。大数据高并发情况下，互联网不怎么使用视图，至少58禁止使用视图
（4）必须遵循“第x范式”的方案
一定不可行。互联网的主要矛盾之一是吞吐量，为了保证吞吐量甚至可能牺牲一些事务性和一致性，通过反范式的方式来确保吞吐量的设计是很常见的，例如：冗余数据。互联网的主要矛盾之二是可用性，为了保证可用性，常见的技术方案也是数据冗余。在互联网数据库架构设计中，第x范式真的没有这么重要
二、哪些方案可行，但文章未提及
（1）提前预留一些reserved字段
这个是可以的。但如果预留过多，会造成空间浪费，预留过少，不一定达得到扩展效果。
（2）通过增加表的方式扩展列，上游通过service来屏蔽底层的细节
这个也是可以的。Jeff同学提到的UserExt(uid, newCol1, newCol2)就是这样的方案（但join连表和视图是不行的）
四、key+value方式使用场景
服务端，wordpress，EAV，配置，统计项等都经常使用这个方案。
客户端（APP或者PC），保存个人信息也经常使用这个方案。
五、在线表结构变更
在《啥，又要为表增加一列属性？》文章的开头，已经说明常见“新表+触发器+迁移数据+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）触发器的建立，会影响原表的性能，所以这个操作建议在流量低峰期进行
pt-online-schema-change是DBA必备的利器，比较成熟，在互联网公司使用广泛。
另外的方法：
开发过程中，当一个表在第一次定义表结构之后需要更新表的结构，那么就不能直接更改，而是进行upgrade操作，这么做的原因是不影响当前项目的正常运行，首先项目如果在客户方部署投入使用，如果你贸然更改表结构会导致用户生产环境数据出问题，数据库混乱，其次对开发环境而言，无论是对自己还是同事，在开发这个项目的时候都会在数据库存入一些数据，那么直接更改表结构也有那样的问题，所以现在大部分都会用以下策略：
现在很多框架都会把数据库表结构放在一个文件中比如
install.xml，把upgrade放在一个文件中，每次定义一个数据库表需要更改表结构时，都需要先在upgrade文件中先更新表结构，然后同步到install.xml文件，然后通过UI进行升级操作
