關於資料儲存型別的一點分析

阿新 • • 發佈：2019-01-18

簡介

SQL Server每個表中各列的資料型別的有各種形式，產生的效果也各有不同，我們主要根據效率兼顧效能的情況下討論下如何規定型別。

在SQL Server中，資料的儲存以頁為單位。八個頁為一個區。一頁為8K，一個區為64K,這個意味著1M的空間可以容納16個區。 SQL Server中的分配單元分為三種，分別為儲存行內資料的In_Row_Data，儲存Lob物件的LOB_Data,儲存溢位資料的Row_Overflow_data。下面我們通過一個更具體的例子來理解這三種分配單元。

我建立如圖2所示的表。

圖2.測試表

圖2的測試表不難看出，通過插入資料使得每一行的長度會超過每頁所能容納的最大長度8060位元組。使得不僅產生了行溢位(Row_Overflow_Data)，還需要儲存LOB的頁.測試的插入語句和通過DBCC IND看到的分配情況如圖3所示。

圖3.超過8060位元組的行所分配的頁

除去IAM頁，這1行資料所需要三個頁來儲存。首先是LOB頁，這類是用於儲存存在資料庫的二進位制檔案所設計，當這個型別的列出現時，在原有的列會儲存一個24位元組的指標，而將具體的二進位制資料存在LOB頁中，除去Text之外，VarBinary(max)也是存在LOB頁中的。然後是溢位行，在SQL Server 2000中，一行超過8060位元組是不被允許的，在SQL Server 2005之後的版本對這個特性進行了改進，使用Varchar,nvarchar等資料型別時，當行的大小不超過8060位元組時，全部存在行內In-row data,當varchar中儲存的資料過多使得整行超過8060位元組時，會將額外的部分存於Row-overflow data頁中，如果update這列使得行大小減少到小於8060位元組，則這行又會全部回到in-row data頁。

資料型別的選擇

在瞭解了一些基礎知識之後。我們知道SQL Server讀取資料是以頁為單位，更少的頁不僅僅意味著更少的IO，還有更少的記憶體和CPU資源消耗。所以對於資料選擇的主旨是:

儘量使得每行的大小更小

這個聽起來非常簡單，但實際上還需要對SQL Server的資料型別有更多的瞭解。

比如儲存INT型別的資料，按照業務規則，能用INT就不用BIGINT,能用SMALLINT就不用INT,能用TINYINT就不用SMALLINT。

所以為了使每行的資料更小，則使用佔位元組最小的資料型別。

1.比如不要使用DateTime型別，而根據業務使用更精確的型別，如下表:

型別
所佔位元組

Date(僅日期)
3

Time(僅時間)
5

DateTime2(時間和日期)
8

DateTimeOffSet(外加時區）
10

2.使用VarChar(Max),Nvarchar(Max),varbinary(Max)來代替text,ntext和image型別

根據前面的基礎知識可以知道，對於text,ntext和image型別來說，每一列只要不為null,即使佔用很小的資料，也需要額外分配一個LOB頁，這無疑佔用了更多的頁。而對於Varchar(Max)等資料型別來說，當資料量很小的時候，存在In-row-data中就能滿足要求，而不用額外的LOB頁，只有當資料溢位時，才會額外分配LOB頁，除此之外，Varchar(Max)等型別支援字串操作函式比如：

COL_LENGTH
CHARINDEX
PATINDEX
LEN
DATALENGTH
SUBSTRING

3.對於僅僅儲存數字的列，使用數字型別而不是Varchar等。

因為數字型別佔用更小的儲存空間。比如儲存123456789使用INT型別只需要4個位元組，而使用Varchar就需要9個位元組(這還不包括Varchar還需要佔用4個位元組記錄長度)。

4.如果沒有必要，不要使用Nvarchar,Nchar等以“字”為單位儲存的資料型別。這類資料型別相比varchar或是char需要更多的儲存空間。

5.關於Char和VarChar的選擇

這類比較其實有一些了。如果懶得記憶，大多數情況下使用Varchar都是正確的選擇。我們知道Varchar所佔用的儲存空間由其儲存的內容決定，而Char所佔用的儲存空間由定義其的長度決定。因此Char的長度無論儲存多少資料，都會佔用其定義的空間。所以如果列儲存著像郵政編碼這樣的固定長度的資料，選擇Char吧，否則選擇Varchar會比較好。除此之外，Varchar相比Char要多佔用幾個位元組儲存其長度，下面我們來做個簡單的實驗。

首先我們建立表，這個表中只有兩個列，一個INT型別的列，另一個型別定義為Char(5)，向其中插入兩條測試資料，然後通過DBCC PAGE來檢視其頁內結構，如圖4所示。

圖4.使用char(5)型別，每行所佔的空間為16位元組

下面我們再來看改為Varchar(5),此時的頁資訊，如圖5所示。

圖5.Varchar(5)，每行所佔用的空間為20位元組

因此可以看出，Varchar需要額外4個位元組來記錄其內容長度。因此，當實際列儲存的內容長度小於5位元組時，使用char而不是varchar會更節省空間。

關於Null的使用

關於Null的使用也是略有爭議。有些人建議不要允許Null,全部設定成Not Null+Default。這樣做是由於SQL Server比較時就不會使用三值邏輯(TRUE,FALSE,UNKNOWN)，而使用二值邏輯(True,False),並且查詢的時候也不再需要IsNull函式來替換Null值。

但這也引出了一些問題，比如聚合函式的時候,Null值是不參與運算的，而使用Not Null+Default這個值就需要做排除處理。

因此Null的使用還需要按照具體的業務來看。

考慮使用稀疏列(Sparse)

稀疏列是對 Null 值採用優化的儲存方式的普通列。稀疏列減少了 Null 值的空間需求，但代價是檢索非 Null 值的開銷增加。當至少能夠節省 20% 到 40% 的空間時，才應考慮使用稀疏列。

稀疏列在SSMS中的設定如圖6所示。

圖6.稀疏列

更具體的稀疏列如何能節省空間，請參看MSDN。

對於主鍵的選擇

對於主鍵的選擇是表設計的重中之重，因為主鍵不僅關係到業務模型，更關係到對錶資料操作的的效率（因為主鍵會處於B樹的非葉子節點中，對樹的高度的影響最多）。這個我們得結合主鍵索引的選擇來具體分析，之前寫過一篇關於索引的，以後有需要再進一步延伸來講

總結

本篇文章對於設計表時，資料列的選擇進行了一些探尋。好的表設計不僅僅是能滿足業務需求，還能夠滿足對效能的優化。