Navicat 部落格

SQL Server 中的 Unicode 和非 Unicode 字串資料類型 2021 年 11 月 19 日,由 Robert Gravelle 撰寫

SQL Server 提供了多種資料類型,支援你想儲存的所有類型的資料。你可能已經猜到,資料類型是一個屬性,用於指定欄可以儲存資料的類型。它可以是整數、字元字串、貨幣、日期和時間等。在資料庫設計人員和開發人員之間引起混淆的一種資料類型是用於儲存字元字串的資料類型。字元字串是作為一組操作的一系列字元。在關聯式資料庫的內容中,字元字串資料類型是那些讓你儲存固定長度(char)或可變長度資料(varchar)的資料類型。此外,SQL Server 將其字串類型分為兩大類:Unicode 和非 Unicode。Unicode 類型有 nchar、nvarchar 和 ntext,而非 Unicode 類型有 char、varchar/varchar (max) 和 text。在今天的文章中,我們將比較這兩個類別,以決定何時使用它們。

追查 Unicode 和非 Unicode 資料類型的起源

nchar 是「NATIONAL CHARACTER」的縮寫,nvarchar 代表「NATIONAL CHARACTER VARYING」,ntext 是「NATIONAL TEXT」的 ISO 同義詞。最初用於 Unicode 之前的多位元組編碼,例如亞洲字元的 JIS 編碼。其想法是 VARCHAR 將繼續用於 ASCII,而 NVARCHAR 就用於非 ASCII 字元。

這個使用案例是在網際網路還處於起步階段和 Unicode 專案起飛之前設計的。在那些日子裡,特別是亞洲語言,他們使用自己特定且互不相容的編碼,如中國大陸的 GB、日語的 JIS/SJIS、香港和台灣的 BIG5、台灣的 CNS 等等。然而,隨著 Unicode 專案編碼的出現,所有這些都發生了變化,正如資料庫供應商意識到的那樣,只允許 VARCHAR 本身支援多位元組字元編碼,並使用字元集和定序來處理特定編碼更容易。例如,你可以使用 UTF-8 對應用程式需要支援的任何語言中所需的任何字元進行編碼。因此,對特定於「NATIONAL CHARACTER」的整組字元資料類型的需求很快就消失了。

現今,在許多現代資料庫引擎中,「NVARCHAR」和「NATIONAL CHARACTER VARYING」實際上只是 VARCHAR 的別名,實際使用幾乎(如果不完全)相同。話雖如此,SQL Server 確實以不同的方式對待這兩者。如文件中所述:

varchar 和 nvarchar 的主要分別在於它們的儲存方式,varchar 儲存為常規 8 位資料(每個字元 1 個位元組),而 nvarchar 儲存每個字元 2 個位元組的資料。由於這個原因,nvarchar 最多可以容納 4000 個字元,它佔用的空間是 SQL varchar 的兩倍。

應使用哪種?

如上所述,在決定使用哪種類型時,最關心的是所使用的儲存量。例如,nvarchar 每個字元使用 2 個位元組,而 varchar 使用 1 個位元組。因為這樣,nvarchar(4000) 使用的儲存空間與 varchar(8000) 相同。因此,如果你需要儲存 UNICODE 或多種語言資料,nvarchar 是最佳選擇。而 varchar 儲存 ASCII 資料,應該是你正常使用時選擇的資料類型。另一個需要考慮的因素是,在査詢中將 VARCHAR 欄聯結至 NVARCHAR(反之亦然)會導致大幅度的效能下降。

總結

在本文中,我們比較了 SQL Server 的 Unicode 和非 Unicode 字串資料類型,以決定何時使用它們。

Navicat 文章
頻道記錄
分享
部落格封存檔