[TOC] ## 使用场景 **数据量大、并发量高场景**，在线数据库属性扩展 ## 不推荐方案 1. `alter table add column` 要坚持这个方案的，也不多解释了，大数据高并发情况下，一定不可行 2. 通过增加表的方式扩展，通过外键join来查询 大数据高并发情况下，join性能较差，一定不可行 3. 通过增加表的方式扩展，通过视图来对外 一定不可行。大数据高并发情况下，互联网不怎么使用视图，至少58禁止使用视图 4. 必须遵循“第x范式”的方案 一定不可行。互联网的**主要矛盾之一是吞吐量**，为了保证吞吐量甚至可能牺牲一些事务性和一致性，通过反范式的方式来确保吞吐量的设计是很常见的，例如：冗余数据。互联网的**主要矛盾之二是可用性**，为了保证可用性，常见的技术方案也是数据冗余。在互联网数据库架构设计中，第x范式真的没有这么重要 ## 推荐方案 “新表+触发器+迁移数据+rename”方案（pt-online-schema-change），这是业内非常成熟的扩展列的方案 基本原理是： 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. 触发器的建立，会影响原表的性能，所以这个操作建议在流量低峰期进行