背景介紹：
服務器 252G/40C SSD盤
mysql版本是5.6.25
表大小：CISXX_DATA_XXX 110908162 rows
第一次嘗試直接加索引
mysql> alter table CISXX_DATA_XXX add column `RESERVED1` varchar(20) NOT NULL DEFAULT '' COMMENT '預留字段1',
-> add column `RESERVED2` varchar(20) NOT NULL DEFAULT '' COMMENT '預留字段2',
-> add column `RESERVED3` varchar(20) NOT NULL DEFAULT '' COMMENT '預留字段3';
ERROR 1878 (HY000): Temporary file write failure.
由於表太大，產生的臨時表已經超出了 /目錄下的磁盤限制。
第二次嘗試新建表
修改新表結構，然后通過insert….select….方式導入數據
create table tmp_CISXX_DATA_XXX_20160620 (……);
insert into tmp_CISXX_DATA_XXX_20160620(….)select … from CISXX_DATA_XXX;
在數據導入的過程中，新開一個會話。測試本次建表過程對cis_data_tag表加的是什么鎖。測試結果如下圖：
由此可知，通過這種方式給cis_data_tag加的是一個共享鎖。
在數據導入的過程中
服務器的負載如下：
磁盤讀寫壓力情況：
在導數過程中發現/目錄下的磁盤空間還是報警了
於是kill掉導數進程，執行kill掉操作后，發現服務器上的內存和磁盤使用率還是在不斷上漲。於是再次嘗試kill。
再次嘗試還是失敗。如果系統資源一直這么消耗小去，可能會導致服務器掛機。但后來發現，磁盤空間到達100%時，該導數進程就被服務器給終止掉了，內存和磁盤空間資源開始釋放。
第三次嘗試修改
因為要操作的表實在太大。而/的磁盤空間又實在太小，為了避免影響產線業務，在第二次修改的基礎上，更改mysql臨時空間的設置。於是整理了如下的解決方案
檢查修改前中
內存的使用率一直在上漲，增長了72G
臨時目錄所在磁盤目錄一直在上漲，增長了72G
磁盤的讀寫率達到了589836.00 wsec/s 172812.00 rsec/s
該表所占的物理文件大小也就48G
在建索引的過程中，發現mysql居然支持在線DDL操作，即不會堵塞其它請求。請看：
這真的是個非常非常偉大的發現，mysql果然進步了。但是聽說mysql只有部分表結構的修改是支持在線的，真是遺憾。
翻閱官方文檔，可以了解更詳細的信息：
修改一張2千萬的表添加字段和加索引所需的時間參考：
修改一張一億的表添加字段和加索引所需的時間參考：
