背景

公司營銷系統前段時間出了一個問題，名單表主鍵是INT類型，經過4年的業務發展，名單ID超過了21億，到達了INT類型的閾值，導致無法接收新的營銷名單。

自救失敗

發現問題原因后，第一時間聯系DBA，請他們幫忙執行一條ddl語句，將名單ID字段類型由INT調整為BIGINT。

很遺憾，由于表的存量數據有5000多萬，ddl無法短時間執行成功。為了避免線上聯機業務長時間受到影響，只能想別的辦法。

騰籠換鳥

名單ID最大值是INT的極大值，存量數據5000多萬，20多億歷史數據是被遷移備份歸檔了的。

聯系到每天新增名單200萬左右，所以新辦法的第一步就是將最進500萬數據的ID，平移到一個歷史區間，這樣就騰出了500萬的ID空間，讓新名單能正常接入，保證業務短期正常。

無阻塞動態修改schema

第一次自救失敗，主要原因是直接修改表字段類型是阻塞式修改，直接影響了線上業務。所以新辦法的第二步就是無阻塞修改表字段類型。DBA推薦了一款工具，PT-ONLINE-SCHEMA-CHANGE，能修改schema而不阻塞其他數據庫操作。

它的原理分為四步：

1. 新建一個變更過schema后的表；
2. 再在原表上建update觸發器、delete觸發器、insert觸發器，確保新的DML操作能同步到新表；
3. 再將原表的數據到按照主鍵ID分區間拷貝到新表；
4. 最后待數據copy完成后，將新表rename成老表。

整個過程幾乎不堵塞的（rename 操作會堵塞，但是rename操作時間很短），但是整體耗時很長。