mysql表扩展方案

事情变得有意思了，上一篇花1小时撰写的“一分钟”文章，又引发了普遍的讨论，说明相关的技术你们感兴趣，挺好。第一次一篇技术文章的评论量过100，才知道原来“评论精选”还有100上限，甚为欣慰（虽然是以一种本身不肯看到的方式）。

 

《啥，又要为表增长一列属性？》的方案很有争议：

（1）版本号version + 扩展字段ext

（2）用增长列的key+value方式扩充属性

 

有些评论，只能说“所谓夏虫，何以语冰”（做者要谦和，请删除）。因本身时间仓促，有些地方没有交代清楚，对不起大伙，实在抱歉。大部分评论仍是在进行技术讨论，故今天再熬夜补充说明一下。

 

零、缘起

讨论问题域：

（1）数据量大、并发量高场景，在线数据库属性扩展

（2）数据库表结构扩展性设计

 

1、哪些方案必定是不行的

（1）alter table add column

要坚持这个方案的，也很少解释了，大数据高并发状况下，必定不可行

 

（2）经过增长表的方式扩展，经过外键join来查询

大数据高并发状况下，join性能较差，必定不可行

 

（3）经过增长表的方式扩展，经过视图来对外

必定不可行。大数据高并发状况下，互联网不怎么使用视图，至少58禁止使用视图

 

（4）必须遵循“第x范式”的方案

必定不可行。互联网的主要矛盾之一是吞吐量，为了保证吞吐量甚至可能牺牲一些事务性和一致性，经过反范式的方式来确保吞吐量的设计是很常见的，例如：冗余数据。互联网的主要矛盾之二是可用性，为了保证可用性，常见的技术方案也是数据冗余。在互联网数据库架构设计中，第x范式真的没有这么重要

 

（5）打产品经理

朋友，这是段子么，这必定不可行

 

2、哪些方案可行，但文章未说起

（1）提早预留一些reserved字段

这个是能够的。但若是预留过多，会形成空间浪费，预留过少，不必定达获得扩展效果。

 

（2）经过增长表的方式扩展列，上游经过service来屏蔽底层的细节

这个也是能够的。Jeff同窗提到的UserExt(uid, newCol1, newCol2)就是这样的方案（但join连表和视图是不行的）

 

3、哪些读者没有仔细看文章

（1）version+ext太弱了，ext不支持索引

回复：属于没有仔细看文章，文章也提了若是有强需求索引可使用MongoDB，它就是使用的json存储（评论中有很多朋友提到，还有其余数据库支持json检索）

 

（2）第二种key+value方案不支持索引

回复：uid能够索引

 

4、key+value方式使用场景

服务端，wordpress，EAV，配置，统计项等都常用这个方案。

客户端（APP或者PC），保存我的信息也常用这个方案。

 

今天的重点

以楼主性格，本不会进行“解释”，上文解释这般，说明这一次，楼主真的认真了。对于技术，认真是好事，认真的男人最可爱（打住，我要吐了）。好了，下面的内容才是今天的重点。

 

5、在线表结构变动

在《啥，又要为表增长一列属性？》文章的开头，已经说明常见“新表+触发器+迁移数据+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必备的利器，比较成熟，在互联网公司使用普遍。

 

楼主非专业的dba，上面的过程有说的不对的地方，欢迎指出。要了解更详细的细节，能够百度一下。有更好的方法，也欢迎讨论，后续会梳理汇总share给更多的朋友。