表字段扩展方案
背景
业务需要,开发了新功能,对应的,需要对原表新增一些必要字段。想当然的
alter table add column
相信很多朋友和我一样,认为没问题。的确,针对一般的项目OK,为啥?因为数据量不大的小站当然没问题,alter造成的也是可以接受的。但是,针对数据量大且并发高的这肯定是有问题的。
于是,博主研究了一些成熟的应对方案。
解决方案
pt-online-schema-change
原理
以user(uid, name, passwd)
扩展到user(uid, name, passwd, age, sex)为例
基本原理是:
- 先创建一个扩充字段后的新表user_new(uid, name, passwd, age, sex)
- 在原表user上创建三个触发器,对原表user进行的所有insert/delete/update操作,都会对新表user_new进行相同的操作
- 分批将原表user中的数据insert到新表user_new,直至数据迁移完成
- 删掉触发器,把原表移走(默认是drop掉)
- 把新表user_new重命名(rename)成原表user
操作过程中需要注意:
- 变更过程中,最重要的是冲突的处理,一条原则,以触发器的新数据为准,这就要求被迁移的表必须有主键(这个要求基本都满足)
- 变更过程中,写操作需要建立触发器,所以如果原表已经有很多触发器,方案就不行(互联网大数据高并发的在线业务,一般都禁止使用触发器)
- 触发器的建立,会影响原表的性能,所以这个操作建议在流量低峰期进行
优点
整个过程不需要锁表,可以持续对外提供服务
建议
以上即为主流的大表新增字段的DBA解决方式,其实,更好的方案是设计表阶段就尽量规划好,有如下两种比较好的方案:
- 预留出足够的字段备用,“足够”怎么理解?需要一个熟悉业务的规划好。预留多了占用不少空间,预留少了也是没有意义,把握好度
- 可以采用“通用基础字段+version字段+ext字段”来设计表,通用基础字段即该表存储数据行的共性字段,ext字段是扩展字段,存储除了共性字段的其它个性字段的json字符串,verison字段用来标识ext代表的意义。注意,mysql此种方式ext中的字段不支持索引和查询(非要采用的话,需要特殊逻辑处理),MongoDB是支持的。
针对数据量不大,并发不高的可以采取简单的方式: - alter table add column
- 新增扩展表,用过联表查询来扩展(切记:大并发,大数据的不能用此方式,性能差劲)
网友评论