幾千萬記錄，資料庫表結構如何平滑變更？

資料量大、併發量高場景，如何在流量低峰期，平滑實施表結構變更?任何脫離業務的架構設計都是耍流氓。 如果是減column，升級程式不使用即可; 如果是修改column，程式相容性容易出問題;

資料量大、併發量高場景，如何在流量低峰期，平滑實施表結構變更?任何脫離業務的架構設計都是耍流氓。
繼續回答知識星球水友提問。

問題域：資料量大、併發量高場景，如何在流量低峰期，平滑實施表結構變更?

畫外音，一般來說，是指增加表的屬性，因為：

如果是減column，升級程式不使用即可;
如果是修改column，程式相容性容易出問題;
首先，一起看下有哪些常見方案。

畫外音：alter table add column

資料量大的情況下，鎖表時間會較長，造成拒絕服務，一般不可行。

舉個例子，對：

t_user(uid, c1, c2, c3)
想要擴充套件屬性，可以透過增加一個表實現：

t_user_ex(uid, c4, c5, c6)
資料量大的情況下，join效能較差，一般不可行。

同上，檢視效率較低，一般不使用檢視。

畫外音：至少58到家禁止使用檢視。

這個方案可行，但如果預留過多，會造成空間浪費。

對於MySQL而言，這是目前比較成熟的方案，被廣大公司所使用。

畫外音：我呆過的網際網路公司，資料庫均使用MySQL。

下面仍以使用者表擴充套件為例，說下這個工具內部的原理與步驟。

假設：

user(uid, name, passwd)

要擴充套件到：

user(uid, name, passwd, age, sex)

第一步，先建立一個擴充欄位後的新表：

user_new(uid, name, passwd, age, sex)

畫外音：就是被擴充套件後的表。

第二步，在原表user上建立三個觸發器，對原表user進行的所有insert/delete/update操作，都會對新表user_new進行相同的操作;

第三步，分批將原表user中的資料insert到新表user_new，直至資料遷移完成;

第四步，刪掉觸發器，把原表移走(預設是drop掉);

第五步，把新表user_new重新命名(rename)成原表user;

擴充欄位完成，整個過程不需要鎖表，可以持續對外提供服務。

操作過程中需要注意：

變更過程中，最重要的是衝突的處理，一條原則，以觸發器的新資料為準，這就要求被遷移的表必須有主鍵(這個要求基本都滿足);
變更過程中，寫操作需要建立觸發器，所以如果原表已經有很多觸發器，方案就不行(網際網路大資料高併發的線上業務，一般都禁止使用觸發器);
觸發器的建立，會影響原表的效能，所以這個操作必須在流量低峰期進行;
pt-online-schema-change是DBA必備的利器，比較成熟，在網際網路公司使用廣泛，要了解更詳細的細節，亦可以Google一下。

任何脫離業務的架構設計都是耍流氓。

原文地址：