最近客戶在和一些國產(chǎn)數(shù)據(jù)庫進行試點測試，發(fā)現(xiàn)一個比較有趣的現(xiàn)象，即有些表數(shù)據(jù)在遷移前后，實際在磁盤中的存儲容量出現(xiàn)了2-3倍的增長，這點歸根結(jié)底得數(shù)據(jù)庫的研發(fā)來回答為什么會出現(xiàn)這一現(xiàn)象，但是我們今天也嘗試從一些蛛絲馬跡來推理一下。

1 數(shù)據(jù)類型

由于我們這里運維的Oracle數(shù)據(jù)庫都開了擴展varchar2長度，即一個varchar2最大可存儲字節(jié)不是4000，而是32k，這樣使得很多原本超長需要使用lob數(shù)據(jù)類型的列可以繼續(xù)使用varchar2，也使得很多寫成varchar2(xx char)的地方不再有超長風(fēng)險。
那么在很多其他數(shù)據(jù)庫，使用varchar數(shù)據(jù)類型（具體請查看各數(shù)據(jù)庫官方文檔）是滿足不了我這里實際數(shù)據(jù)的存儲需求的。那么在遷移過后就需要變換字段的數(shù)據(jù)類型，在本次案例中，就出現(xiàn)了不少varchar轉(zhuǎn)換為text的操作。那么以MySQL為例對比一下varchar和text：

• varchar：一種可變長度的字符串?dāng)?shù)據(jù)類型，用于存儲可變長度的字符數(shù)據(jù)。它的定義包括存儲支持的最大長度，表示該列可以存儲的最大字節(jié)長度。存儲方式與其長度有關(guān)。當(dāng)存儲varchar值時，MySQL會根據(jù)實際的數(shù)據(jù)長度分配足夠的存儲空間。
• text：一種用于存儲大量文本數(shù)據(jù)的數(shù)據(jù)類型。它可以存儲非常長的字符串，最大長度取決于數(shù)據(jù)庫的配置。總是占用足夠的存儲空間以容納其最大長度。無論實際存儲的文本數(shù)據(jù)有多長，都會占用足夠的存儲空間。

那么從兩種數(shù)據(jù)類型的對比來看，就可以知道使用text存儲字段占用的存儲空間肯定是大于varchar的。那么我們可以把這個當(dāng)做第一個可能的原因。

2 索引

這個問題我也在群里問過各位大佬，一位大佬說了一句，他在使用一款和Oracle兼容性非常高的數(shù)據(jù)庫產(chǎn)品時候發(fā)現(xiàn)，這個數(shù)據(jù)庫索引的存儲空間占用是大于Oracle數(shù)據(jù)庫中的索引。索引這個事情除了與上一節(jié)說的數(shù)據(jù)類型有關(guān)，還與本身索引結(jié)構(gòu)的構(gòu)建有關(guān)系。這里可以當(dāng)做第二個可能的原因。

3 存儲引擎

其實結(jié)合上一點，不同的數(shù)據(jù)庫有不同的存儲引擎，那么在數(shù)據(jù)塊的構(gòu)建上就可能千差萬別，這個不僅僅體現(xiàn)在索引的存儲上，也體現(xiàn)在數(shù)據(jù)本身的存儲上。那么有些存儲引擎或者說叫數(shù)據(jù)存儲的樹形結(jié)構(gòu)從理論層面是可以節(jié)省存儲空間的，而有些確實會占用更多空間。這里當(dāng)作第三個可能的原因。

總結(jié)

這里并沒有說具體數(shù)據(jù)庫之間的存儲差異，說真的也不大敢得罪任意一家數(shù)據(jù)庫，我也希望大家在做國產(chǎn)數(shù)據(jù)庫選型、測試的時候可以考慮的更全面一點。還可能有哪些原因也希望大家留言、私信補充。
老規(guī)矩，不知道寫了些啥。