前言

? ? ? ? 這個是源自于昨天寫的業務背景，對接蘋果支付退款退單接口-CSDN博客

? ??

? ? ? ? 涉及到了order表的改動，而目前order表已經有2千萬的數據，如果退款字段都直接加在這張表里面可能會比較慢，所以才有這篇文章，文章里只討論思路，而不進行具體的編碼實現，真正操作需要自己去注意細節

大表添加思路字段

直接加

? ? ? ? 也就是直接利用 alter table add 命令加，這種是最原始的，可能比較慢，這里就不討論了

阿里云操作

? ? ? ? 參考地址：如何進行無鎖結構變更_數據管理 DMS-阿里云幫助中心

程序處理

基礎版本

1. 對 order 數據表結構進行復制，放到一張新表里面 order_back(只包含結構)
2. 在order_back里面添加需要的字段(沒數據加字段很快)
3. 把order的數據轉移到order_back里面去
4. 把order_back和order表名進行互換即可

這種版本就是中間轉移數據會比較慢，其他的還行

進階版本

1. 對 order 數據表結構進行復制，放到一張新表里面 order_back(只包含結構)
2. 在order_back里面添加需要的字段(依然很慢，但是不影響業務)
3. 把這段時間內order產生的數據插入到order_back上
4. 替換表名

這種版本可以節省后面轉移數據的等待時間，在第1步就處理了，但是這里仍然有問題，假設中級order表有更新那么order_back是不知道的，其實基礎版本也有這個問題，雖然訂單表一般支付后就不會改了，但是還是有可能會發生，解決方案如下

進階版本-改版1

? ? ? ?就是數據轉移完以后不是直接把原有的order刪掉，而是等轉移以后，再起一個定時器去掃描，等到數據處理完成以后再把定時器去掉即可

? ? ? ? 這種方式確實可以做到最終同步，但是還是比較麻煩，需要借助定時器處理后續邏輯

進階版本-改版2

? ? ? ? 我們其實可以考慮一個問題，其實核心就是怕有數據的修改而引起數據不同步，一般做法可能就是在代碼里面添加邏輯去記錄修改的記錄然后轉移完成以后進行更新，這種方式確實可以，但是還可以用一種更妙的方式處理

? ? ? ? 就是我們再起一張結構跟order一樣的order_update表，然后在order表添加一個觸發器，當有修改的時候把新的數據插到order_update上，這樣一來就很好處理了，當前面的數據遷移完畢以后，我們只需要再掃一下order_update的數據，然后進行對應的修改就行了

? ? ? ? 這種做法就不用在程序里去記錄修改了，也不需要用定時器處理了，當然了這里也可以監控binlog(原理跟這個差不多)

結語

? ? ? ? 到這里就結束了，以上是我的幾種方式，如果有問題或者大家有更好的方案，可以提起來一起討論一下

mysql 8.0 版本，INSTANT 算法，可以參考文章

? ? ? ?在？上次你問對大型表的DDL操作，我找到好方法了 - 知乎