TEXT欄位是否有必要拆分成獨立表？

最近不止一次的被問及這麼乙個問題：

乙個含有text欄位的寬表，是否有必要把text拆分出去作為乙個獨立的表，來提高效能？

其有利之處主要體現在下面三個方面：

ps：以下的討論物件均基於innodb引擎

由於目前innodb-plugin對於大多數ddl都是會有table-lock的。這也就意味著，一張表的ddl時間越長，業務的不可訪問時間也就越長。

而決定一條ddl命令執行時長的兩個關鍵因素就是：錶行數，表物理檔案大小。

text欄位的拆分獨立，能夠很有效的減小主表的物理檔案大小。

由此不難看出一張對於業務十分重要或者訪問非常頻繁的表來說，這樣的拆分是能夠極大程度上降低運維成本的。

key-大體積value的資料型別對於mysql來說本來就不是乙個強項。

將text拆分成k-v這樣簡單結構的表後，很方便就能通過改動較少的**，實現資料產品的遷移。

無論是mongo的 _id: value 、redis 的string 、還是memcached的key - value 都可以很輕鬆的匯入資料。

此外，拋開快取方案不說，光基於節省mysql磁碟空間的考慮，也可以對於拆分後的獨立表單獨配置 row-format = compressed 的innodb壓縮引數。減小物理檔案體積，同時也增多了單個資料頁能夠存放的內容，一定程度上的提公升了qps。

上文提到了，拆分後新增壓縮選項後，k-v表的qps會較之前有提公升。

除此之外，這種方案對於 antelope檔案格式的主表查詢效能也會有提公升（barracuda檔案格式則沒有區別）。

由於antelope的 compact和redundant檔案格式，對於長字段都會將其最左的786個位元組內容儲存在primary key的資料頁中。

而barracuda 的檔案格式，對於text欄位，都會將其全部內容存放在off-page中，而primary key的資料頁中只存放乙個20位元組的指標。

拆分對於前者可以節省786b的資料頁空間，而後者只有20b的空間。這也就是為什麼，前者的效能提公升會更大

有規律欄位的拆分

在很多的時候，我們會經常遇到將資料庫的某乙個字段拆分的問題，當然前提條件是字段的資訊是有規律的，比如說乙個字段存在 這樣的資訊 aaaaa,bbbbb,ccccc,zzzz,tttt 需要你將其根據 分開後，然後將所有資料放入另外乙個表中。其實這就是乙個典型的charindex函式的應用。我們先看看...

有規律欄位的拆分

在很多的時候，我們會經常遇到將資料庫的某乙個字段拆分的問題，當然前提條件是字段的資訊是有規律的，比如說乙個字段存在 這樣的資訊 aaaaa,bbbbb,ccccc,zzzz,tttt 需要你將其根據 分開後，然後將所有資料放入另外乙個表中。其實這就是乙個典型的charindex函式的應用。我們先看看...

MySQL 分割槽欄位列是否有必要再單獨建索引

對於分割槽字段必須是主鍵的一部分，那麼建了復合主鍵之後，是否需要對分許字段再單獨新增乙個索引呢？有沒有效果？下面來驗證一下 create table effect new id bigint 20 not null auto increment,type tinyint 4 not null def...