這才是真正的表擴(kuò)展方案

事情變得有意思了，上一篇花1小時(shí)撰寫的“一分鐘”文章，又引起了廣泛的討論，說明相關(guān)的技術(shù)大家感興趣，挺好。第一次一篇技術(shù)文章的評(píng)論量過100，才知道原來“評(píng)論精選”還有100上限，甚為欣慰（雖然是以一種自己不愿看到的方式）。

《啥，又要為表增加一列屬性？》的方案頗有爭(zhēng)議：

（1）版本號(hào)version + 擴(kuò)展字段ext

（2）用增加列的key+value方式擴(kuò)充屬性

因自己時(shí)間倉(cāng)促，有些地方?jīng)]有交代清楚，對(duì)不起大伙，實(shí)在抱歉。大部分評(píng)論還是在進(jìn)行技術(shù)討論，故今天再熬夜補(bǔ)充說明一下。

零、緣起

---

討論問題域：

（1）數(shù)據(jù)量大、并發(fā)量高場(chǎng)景，在線數(shù)據(jù)庫(kù)屬性擴(kuò)展

（2）數(shù)據(jù)庫(kù)表結(jié)構(gòu)擴(kuò)展性設(shè)計(jì) 

一、哪些方案一定是不行的

---

（1）alter table add column

要堅(jiān)持這個(gè)方案的，也不多解釋了，大數(shù)據(jù)高并發(fā)情況下，一定不可行

（2）通過增加表的方式擴(kuò)展，通過外鍵join來查詢

大數(shù)據(jù)高并發(fā)情況下，join性能較差，一定不可行

（3）通過增加表的方式擴(kuò)展，通過視圖來對(duì)外

一定不可行。大數(shù)據(jù)高并發(fā)情況下，互聯(lián)網(wǎng)不怎么使用視圖，至少58禁止使用視圖

（4）必須遵循“第x范式”的方案

一定不可行?；ヂ?lián)網(wǎng)的主要矛盾之一是吞吐量，為了保證吞吐量甚至可能犧牲一些事務(wù)性和一致性，通過反范式的方式來確保吞吐量的設(shè)計(jì)是很常見的，例如：冗余數(shù)據(jù)?；ヂ?lián)網(wǎng)的主要矛盾之二是可用性，為了保證可用性，常見的技術(shù)方案也是數(shù)據(jù)冗余。在互聯(lián)網(wǎng)數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)中，第x范式真的沒有這么重要

（5）打產(chǎn)品經(jīng)理

朋友，這是段子么，這一定不可行

二、哪些方案可行，但文章未提及

---

（1）提前預(yù)留一些reserved字段

這個(gè)是可以的。但如果預(yù)留過多，會(huì)造成空間浪費(fèi)，預(yù)留過少，不一定達(dá)得到擴(kuò)展效果。

（2）通過增加表的方式擴(kuò)展列，上游通過service來屏蔽底層的細(xì)節(jié)

這個(gè)也是可以的。Jeff同學(xué)提到的UserExt(uid, newCol1, newCol2)就是這樣的方案（但join連表和視圖是不行的）

三、哪些讀者沒有仔細(xì)看文章

---

（1）version+ext太弱了，ext不支持索引

回復(fù)：屬于沒有仔細(xì)看文章，文章也提了如果有強(qiáng)需求索引可以使用MongoDB，它就是使用的json存儲(chǔ)（評(píng)論中有不少朋友提到，還有其他數(shù)據(jù)庫(kù)支持json檢索）

（2）第二種key+value方案不支持索引

回復(fù)：uid可以索引

四、key+value方式使用場(chǎng)景

---

服務(wù)端，wordpress，EAV，配置，統(tǒng)計(jì)項(xiàng)等都經(jīng)常使用這個(gè)方案。

客戶端（APP或者PC），保存?zhèn)€人信息也經(jīng)常使用這個(gè)方案。

今天的重點(diǎn)

以樓主性格，本不會(huì)進(jìn)行“解釋”，上文解釋這般，說明這一次，樓主真的認(rèn)真了。對(duì)于技術(shù)，認(rèn)真是好事，認(rèn)真的男人最可愛（打住，我要吐了）。好了，下面的內(nèi)容才是今天的重點(diǎn)。

五、在線表結(jié)構(gòu)變更

---

在《啥，又要為表增加一列屬性？》文章的開頭，已經(jīng)說明常見“新表+觸發(fā)器+遷移數(shù)據(jù)+rename”方案（pt-online-schema-change），這是業(yè)內(nèi)非常成熟的擴(kuò)展列的方案（以為大伙都熟悉，沒有展開講，只重點(diǎn)講了兩種新方案，這可能是導(dǎo)致被噴得厲害的源頭），今天補(bǔ)充說一下。

以user(uid, name, passwd)

擴(kuò)展到user(uid, name, passwd, age, sex)為例

基本原理是：

（1）先創(chuàng)建一個(gè)擴(kuò)充字段后的新表user_new(uid, name, passwd, age, sex)

（2）在原表user上創(chuàng)建三個(gè)觸發(fā)器，對(duì)原表user進(jìn)行的所有insert/delete/update操作，都會(huì)對(duì)新表user_new進(jìn)行相同的操作

（3）分批將原表user中的數(shù)據(jù)insert到新表user_new，直至數(shù)據(jù)遷移完成

（4）刪掉觸發(fā)器，把原表移走（默認(rèn)是drop掉）

（5）把新表user_new重命名（rename）成原表user

擴(kuò)充字段完成。

優(yōu)點(diǎn)：整個(gè)過程不需要鎖表，可以持續(xù)對(duì)外提供服務(wù)

操作過程中需要注意：

（1）變更過程中，最重要的是沖突的處理，一條原則，以觸發(fā)器的新數(shù)據(jù)為準(zhǔn)，這就要求被遷移的表必須有主鍵（這個(gè)要求基本都滿足）

（2）變更過程中，寫操作需要建立觸發(fā)器，所以如果原表已經(jīng)有很多觸發(fā)器，方案就不行（互聯(lián)網(wǎng)大數(shù)據(jù)高并發(fā)的在線業(yè)務(wù)，一般都禁止使用觸發(fā)器）

（3）觸發(fā)器的建立，會(huì)影響原表的性能，所以這個(gè)操作建議在流量低峰期進(jìn)行

pt-online-schema-change是DBA必備的利器，比較成熟，在互聯(lián)網(wǎng)公司使用廣泛。

樓主非專業(yè)的dba，上面的過程有說的不對(duì)的地方，歡迎指出。要了解更詳細(xì)的細(xì)節(jié)，可以百度一下。有更好的方法，也歡迎討論，后續(xù)會(huì)梳理匯總share給更多的朋友。

六、結(jié)束

---

歡迎用批判的眼光看問題，歡迎任何友善的技術(shù)討論，不太歡迎“純屬誤導(dǎo)”“非常蠢的方案”這樣的評(píng)論（但我還是會(huì)加精選，任何人都有發(fā)聲的權(quán)利）。

借評(píng)論中@張九云 朋友的一句話“不要以為自己見過的就是全世界，任何方案都有使用場(chǎng)景，一切都是tradeoff”作為今天的結(jié)尾，謝謝大家的支持，感謝大家。