爲表增長一列屬性（補充）

事情變得有意思了，上一篇花1小時撰寫的「一分鐘」文章，又引發了普遍的討論，說明相關的技術你們感興趣，挺好。第一次一篇技術文章的評論量過100，才知道原來「評論精選」還有100上限，甚爲欣慰（雖然是以一種本身不肯看到的方式）。

 

《啥，又要爲表增長一列屬性？》的方案很有爭議：

（1）版本號version + 擴展字段ext

（2）用增長列的key+value方式擴充屬性

 

有些評論，只能說「所謂夏蟲，何以語冰」（做者要謙和，請刪除）。因本身時間倉促，有些地方沒有交代清楚，對不起大夥，實在抱歉。大部分評論仍是在進行技術討論，故今天再熬夜補充說明一下。

 

零、緣起

討論問題域：

（1）數據量大、併發量高場景，在線數據庫屬性擴展

（2）數據庫表結構擴展性設計

 

1、哪些方案必定是不行的

（1）alter table add column

要堅持這個方案的，也很少解釋了，大數據高併發狀況下，必定不可行

 

（2）經過增長表的方式擴展，經過外鍵join來查詢

大數據高併發狀況下，join性能較差，必定不可行

 

（3）經過增長表的方式擴展，經過視圖來對外

必定不可行。大數據高併發狀況下，互聯網不怎麼使用視圖，至少58禁止使用視圖

 

（4）必須遵循「第x範式」的方案

必定不可行。互聯網的主要矛盾之一是吞吐量，爲了保證吞吐量甚至可能犧牲一些事務性和一致性，經過反範式的方式來確保吞吐量的設計是很常見的，例如：冗餘數據。互聯網的主要矛盾之二是可用性，爲了保證可用性，常見的技術方案也是數據冗餘。在互聯網數據庫架構設計中，第x範式真的沒有這麼重要

 

（5）打產品經理

朋友，這是段子麼，這必定不可行

 

2、哪些方案可行，但文章未說起

（1）提早預留一些reserved字段

這個是能夠的。但若是預留過多，會形成空間浪費，預留過少，不必定達獲得擴展效果。

 

（2）經過增長表的方式擴展列，上游經過service來屏蔽底層的細節

這個也是能夠的。Jeff同窗提到的UserExt(uid, newCol1, newCol2)就是這樣的方案（但join連表和視圖是不行的）

 

3、哪些讀者沒有仔細看文章

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

回覆：屬於沒有仔細看文章，文章也提了若是有強需求索引可使用MongoDB，它就是使用的json存儲（評論中有很多朋友提到，還有其餘數據庫支持json檢索）

 

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

回覆：uid能夠索引

 

4、key+value方式使用場景

服務端，wordpress，EAV，配置，統計項等都常用這個方案。

客戶端（APP或者PC），保存我的信息也常用這個方案。

 

今天的重點

以樓主性格，本不會進行「解釋」，上文解釋這般，說明這一次，樓主真的認真了。對於技術，認真是好事，認真的男人最可愛（打住，我要吐了）。好了，下面的內容纔是今天的重點。

 

5、在線表結構變動

在《啥，又要爲表增長一列屬性？》文章的開頭，已經說明常見「新表+觸發器+遷移數據+rename」方案（pt-online-schema-change），這是業內很是成熟的擴展列的方案（覺得大夥都熟悉，沒有展開講，只重點講了兩種新方案，這多是致使被噴得厲害的源頭），今天補充說一下。

 

以user(uid, name, passwd)

擴展到user(uid, name, passwd, age, sex)爲例

 

基本原理是：

（1）先建立一個擴充字段後的新表user_new(uid, name, passwd, age, sex)

（2）在原表user上建立三個觸發器，對原表user進行的全部insert/delete/update操做，都會對新表user_new進行相同的操做

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

（4）刪掉觸發器，把原表移走（默認是drop掉）

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

擴充字段完成。

 

優勢：整個過程不須要鎖表，能夠持續對外提供服務

 

操做過程當中須要注意：

（1）變動過程當中，最重要的是衝突的處理，一條原則，以觸發器的新數據爲準，這就要求被遷移的表必須有主鍵（這個要求基本都知足）

（2）變動過程當中，寫操做須要創建觸發器，因此若是原表已經有不少觸發器，方案就不行（互聯網大數據高併發的在線業務，通常都禁止使用觸發器）

（3）觸發器的創建，會影響原表的性能，因此這個操做建議在流量低峯期進行

 

pt-online-schema-change是DBA必備的利器，比較成熟，在互聯網公司使用普遍。

 

樓主非專業的dba，上面的過程有說的不對的地方，歡迎指出。要了解更詳細的細節，能夠百度一下。有更好的方法，也歡迎討論，後續會梳理彙總share給更多的朋友。

 

6、結束

歡迎用批判的眼光看問題，歡迎任何友善的技術討論，不太歡迎「純屬誤導」「很是蠢的方案」這樣的評論（但我仍是會加精選，任何人都有發聲的權利）。

 

借評論中@張九雲 朋友的一句話「不要覺得本身見過的就是全世界，任何方案都有使用場景，一切都是tradeoff」做爲今天的結尾，謝謝你們的支持，感謝你們。

 

原文連接：https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959765&idx=1&sn=b9916aa95c320e41035977e0a8098ca6&chksm=bd2d04098a5a8d1f3af38f658c05002151e621170949d2e3bb5b1bceea55c64b0477dba4c647&scene=21#wechat_redirect