MySQL 千萬級別大資料量的表新增新字段時踩的坑

最近在公升級乙個老的mysql專案時需要在一張老表：t_order_goods中新增是否虛擬商品標示字段：isvirual,開發人員在自己的開發環境完美的做好加欄位操作，並成功提交到測試環境，測試人員也在預發布環境完美的測試通過，然後在發布生產當天意外出現了。。。具體細節請仔細看下文

公司的dba同事接到開發的加字段的指令碼：

alter table t_order_goods add column isvirtual int default 0;

看到此指令碼，也麼有任何問題，資深的dba同事就直接execute了，然後出乎大家意料的是竟然執行此指令碼時客戶端mysqlworkbench超時了，意味著第一次執行失敗了！

然後我們的dba同事查了下該錶的資料量，大概在一千萬，分析了下可能是資料量大導致加欄位超時了，於是毫不猶豫查了度娘調整了客戶端 mysqlworkbench的超時時間

1、首先第乙個問題是生產環境執行失敗，開發+預發布環境都可以執行成功，大家一致的意見就是表：t_order_goods資料量幾個環境不一樣，生產環境資料量偏大

2、生產環境mysql的版本是5.7 ，出現幾次失敗專案組的開發人員都很積極去度娘，發現mysql5.xx版本之前都有類似的問題，凡事大資料表新增欄位都會很慢，一旦執行新增字段操作嚴重的會拖垮整個資料庫伺服器；而8.0.xx之後的版本引入了新的演算法，基本上執行加欄位操作很快，幾乎是毫秒級的操作

題外話，我們的dba同事是專業的資深sql server專家，對mysql不是特別擅長，本次發布也是對mysql又是狠狠的鄙視

1、擴充套件一張新的表，t_order_goods_ext ，新增關聯t_order_goods表的字段good_id, 是否虛擬商品標示字段:isvirtual

2、將涉及到本次業務的虛擬商品goodid初始化到擴充套件表中，不用遷移t_order_goods老表的資料，這樣資料量瞬間很小了

3、調整應用層的程式呼叫**，將涉及到操作t_order_goods表的地方改為左關聯擴充套件表t_order_goods_ext

方案

二、老表資料遷移四部曲方案

1、新建老表t_order_goods的備份表t_order_goods_bak，同時加乙個字段：isvirtual 並給預設值

2、遷移老表t_order_goods資料到備份表t_order_goods_bak中

3、刪除老表t_order_goods

4、新命名備份表t_order_goods_bak表名為t_order_goods

以上的操作步驟2~4建議是在離線的情況下執行，避免在執行遷移資料過程中有新資料進來，導致新錶資料流失不完整

方案

三、公升級mysql的伺服器版本

1、將現有mysql版本5.7公升級到8.0.12之後的版本

2、然後再執行新增字段操作

以上幾個方案優勢劣勢對比

方案一：

優勢：開發人員可以快速的定位相關影響點

劣勢: 一旦新錶的資料量一樣的會耗時很長

方案二：

優勢：不用再調整業務層的應用程式**，只需要dba遷移表即可

劣勢：新錶可能會跟老表資料不一致，資料不完整；離線操作過長可能會影響其他業務的正常執行

方案三：

優勢：不影響業務層的應用程式**，也不會導致資料丟失

劣勢：公升級過程，必然要離線，此過程時間過程一樣會影響業務的正常執行

個人建議在實際情況允許的情況下，如果大家所在的公司也出現類似的問題時，盡可能的還是採用方案三：公升級伺服器版本

畢竟長遠考慮，後續在業務的發展不確定情況下，原始表拓展加新的字段是很正常的一件事，公升級到高版本後因為引入了新的演算法：即時演算法所以會毫秒級別的加欄位不會對業務發布上線造成影響

具體引入的即時演算法：instant 在稍後的章節做詳細闡述~~