需求源产品***版本：用户有三个属性：用户名，密码，昵称，对应表设计：user(uid,name,passwd,nick)在第二个版本中，产品经理增加了age和gender两个属性,表结构可能会改成：user(uid,name,passwd,nick,age,sex)假设数据量和并发比较大，怎么改呢？(1)altertableaddcolumn?不可行，锁表时间长（2）新建表+触发器？如果数据量太大，新表可能放不下，何况触发器对数据库性能的影响还是比较大的（3）让dba来做？新建表、数据迁移、一致性校验、重命名？dba今天真的好辛苦分享2个专栏的扩展性设计的几个小技巧，只需要大家1分钟（如果下班太晚，只能写一个系列一分钟=_=）选项一：版本number+generalcolumn以上面的user表为例，假设只有uid和name有查询需求，表可以设计为user(uid,name,version,ext)(1)uid和name有查询需求，即必须设计成单独的列并创建Index(2)version是版本号字段，说明ext的版本(3)ext使用一个可扩展的字符串协议载体来携带要查询的属性。比如刚上线的时候version是0，现在只有passwd和nick这两个属性，那么数据就是：当产品经理需要扩展属性的时候，新的data会把version改成1，并且此时添加了age和sex这两个数据，数据就变成了：优点：（1）可以随时使用动态扩展属性（2）新旧数据可以同时存在（3）方便迁移数据，写一个小程序把旧版本的ext换成新版本的ext，修改版本不足：（1）ext中的字段无法创建索引（2）ext中的键值有很多冗余。建议缩短key并改进：(1)如果ext中的属性有索引需求，MongoDB等Nosql可能更适合方案二：通过扩展rows属性来扩展以上面的user表为例，它可以设计成user(uid,key,value)最初有name,passwd,nick三个属性，那么数据就是：age和sex这两个属性，以后会扩展，数据变成：advantages:(1)可以随时动态扩展属性(2)新旧数据可以同时存在(3)方便迁移数据，写个小程序增加新属性(4)每个属性都可以查询不足:(1)key值有很多冗余，建议key短一些ldquo;version+ext”或者“key+value”来满足产品新栏目的需求，希望你没有浪费这一分钟，有所收获。【本文为专栏作者原创稿件】58神剑》，转载请联系原作者]
