事情变得有趣了。上一篇花了一个小时写的“一分钟”文章引起了广泛的讨论，说明大家对相关技术感兴趣，这是非常好的。第一次技术文章的评论数超过100，才发现“评论精选”还有100条的限制，很欣慰（虽然是我以前没有的方式）不想看）。《啥，又要为表增加一列属性?》的提议比较有争议：（1）版本号version+扩展字段ext（2）通过增加列key+value的方式扩展属性。由于时间有限，有些地方没有解释清楚。对不起大家，真的很抱歉。大部分评论还是技术讨论，今天熬夜补充说明。零、起源讨论问题领域：（1）大数据量，高并发场景，在线数据库属性扩展（2）数据库表结构扩展性设计1.哪些方案一定不行（1）altertableaddcolumn必须坚持这个我不需要解释太多关于解决方案。在大数据高并发的情况下，肯定是行不通的。(2)通过加表进行扩展，使用外键连接查询大数据。在高并发的情况下，join性能很差，肯定不可行。(3)加表扩展一定不能通过视图对外使用。在大数据高并发的情况下，互联网用的视图不多，至少58禁止使用视图(4)必须遵循“xth范式”的方案肯定是行不通的。互联网的主要矛盾之一是吞吐量。为了保证吞吐量，甚至会牺牲一些事务和一致性。通过反范式的方法来保证吞吐量的设计是很常见的，比如冗余数据。互联网的第二个主要矛盾是可用性。为了保证可用性，常见的技术方案也是数据冗余。在互联网数据库架构的设计中，xth范式真的没有那么重要这对于保留字段来说是有可能的。但是预留太多会浪费空间，预留太少又可能达不到扩展的效果。(2)也可以通过加表的方式扩展列，也可以让上游通过服务屏蔽底层细节。Jeff提到的UserExt(uid,newCol1,newCol2)就是这样的解决方案（但是jointablesandviews是不行的）3.哪位读者没仔细看文章（1）version+ext太弱，ext不支持indexes回复：没仔细看文章。文章中也提到如果有强烈的需求索引，可以使用MongoDB，就是使用的json存储（很多朋友在评论中提到，还有其他数据库支持json检索）（2）第二种key+value方案doesnotsupportindexreply:uidcanbeindexed4.场景服务器使用key+value的方式，wordpress，EAV，配置，统计项等在这个方案中经常用到。客户端（APP或PC）经常使用该方案保存个人信息。今天的重点是主持人的人品，我就不“解释”了。从上面的解释可以看出，楼主这次是认真的。对于技术来说，认真是好事，认真的男人最可爱（住手，我要吐了）。好了，下面的内容就是今天的重点了。5.在线表结构更改《啥，又要为表增加一列属性?》文章开头已经说明，常见的“新建表+触发器+迁移数据+重命名”方案（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批量插入数据到新表user_new，直到数据迁移完成(4)删除trigger，移除原表(默认drop)(5)重命名（rename）新表user_new给原表user扩展字段完成。优点：整个过程不需要锁表，可以持续对外提供服务。操作过程中应注意：(1)变更过程中，最重要的是处理冲突。一个原则是以触发器的新数据为准，这就要求被迁移的表必须有主键（基本满足这个要求）(2)变更过程中，需要创建触发器进行写操作，所以如果原表已经有很多触发器，解决方案不行（互联网大数据，高并发的在线业务，一般禁止使用触发器）（3）触发器的建立会影响原表的性能，所以这个操作建议在流量低峰期执行pt-online-schema-change。广泛应用于互联网公司。楼主是非专业dba，以上过程有错误，欢迎指出。更详细的可以百度。如果有更好的方法欢迎大家一起讨论，以后我会整理出来分享给更多的朋友。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】
