总的来说，这是一次草率的升级行为。
备注：
- MySQL 5.6.23-72.1 innodb, 非SSD盘;
- CentOS 6, 64 bit
作死特征:
- 在线更新，不停服；
- 大白天。上午10点左右，属于我们业务的高峰期；
- 表数据量大， ～2800w 行；
- 修改的是 Email 认证表，事关 Email 登录注册。
对应的 SQL 语句是：
1 | ALTER TABLE `emailauth` ADD COLUMN `status` ENUM("checked", "unchecked") NOT NULL DEFAULT "checked"; |
就一普通的加字段 sql。但是一旦时机不对，就是作死了。还好没有中断操作，不然后果严重！
操作的结果：
1 | Query OK, 0 rows affected (17 min 1.03 sec) |
反正这17分钟是胆颤心惊的。操作的过程中，系统负载高，磁盘IO 高， 达 80%。万幸的是，居然没影响登录！估计会影响注册，因为 alter table 会锁表，只读。还好升级期间没有用户反馈这种问题。
Alter table 到底发生了什么事呢？ 引用别人的文章：
首先要明确alter table操作的流程：
- 旧表加写锁（旧表只读操作）
- 依据旧表结构创建临时表
- 修改临时表结构
- 从旧表中取出数据插入临时表，同时删除旧表
- 临时表做重命名操作
- 刷新数据字典，释放写锁
从上面的流程可以知道，如果是千万级别以上的大表，执行创建临时表的步骤将非常缓慢（锁表），而且会消耗大量系统资源（磁盘IO操作）。
总结：
- 个人状态不佳。可能是因为最近重构的项目不能上线，被驳回了，感到不爽；
- 升级前一定要评估好各种风险，一般来说这种改表操作适合在凌晨进行；
- 对于此次升级，大家都没有很在意，以至于没有协商好；
17min 分钟，2800w，SAS盘, 获得这一数据也算是这次的最大收获，方便以后评估类似操作。
参考：
