Unicode 的儲存和效能效果
SQL Server 使用 UCS-2 編碼配置儲存 Unicode 資料。在此機制下,所有的 Unicode 字元都使用 2 個位元組來儲存。
儲存 Unicode 與非 Unicode 字元資料的差異在於非 Unicode 資料是否使用雙位元組字集來儲存。所有的非東亞語言與泰文均以單位元組來儲存非 Unicode 字元。因此,將這些語言儲存為 Unicode 將需使用兩倍的空間來指定非 Unicode 字碼頁。另一方面,許多其他亞洲語言的非 Unicode 字碼頁都指定以雙位元組字集 (DBCS) 來儲存字元。因此,對於這些語言而言,不論以非 Unicode 或 Unicode 儲存幾乎都沒有差別。
下表顯示指定以雙位元組字集儲存字元資料的非 Unicode 字碼頁。
Language |
字碼頁 |
---|---|
簡體中文 |
936 |
繁體中文 |
950 |
日文 |
932 |
韓文 |
949 |
Unicode 資料的效能影響由於下列各種因素而顯得複雜:
Unicode 排序規則與非 Unicode 排序規則的差異
排序雙位元組與單位元組字元的差異
用戶端與伺服器之間字碼頁的轉換
SQL Server 使用 Unicode 排序規則來執行以 Windows 定序所定義的非 Unicode 資料的字串比較。因為這些規則比非 Unicode 排序規則還要更複雜,所以它們需要更大量的資源。因此,雖然 Unicode 排序規則通常成本比較高,不過大致上以 Windows 定序的 Unicode 資料與非 Unicode 資料,在效能上並沒有太大的差異。
SQL Server 使用非 Unicode 排序規則的唯一情況是,在以 SQL 定序所定義的非 Unicode 資料上使用。在此實例中的排序和掃描通常會比套用 Unicode 排序規則的速度還快。Unicode 排序規則適用於以 Windows 定序或 SQL 定序定義的所有 Unicode 資料。
其次,排序許多 Unicode 資料可能會比非 Unicode 資料更慢,因為是以雙位元組儲存資料。另一方面,以 Unicode 排序亞洲字元會比排序特定字碼頁的亞洲 DBCS 資料更快,因為 DBCS 資料實際上是混合單位元組與雙元組寬度,而 Unicode 字元則是固定寬度。
其他的效能問題主要取決於轉換 SQL Server 執行個體與用戶端之編碼機制的問題。一般而言,用戶端/伺服器字碼頁轉換的效能影響是可以忽略的。無論如何,您應該瞭解此層面所發生的一切。
ODBC API 3.6 版或更舊的版本以及 DB-Library API 無法辨識 Unicode。對於使用這些 API 所定義的資料存取方法之用戶端,會使用資源將 Unicode 資料隱含轉換為用戶端字碼頁。另外,當用戶端字碼頁無法辨識某些 Unicode 字元時,用戶端的資料將有損毀的風險。
ODBC 的較新版本,從 Microsoft Data Access Components 2.7 版 (包含在 SQL Server 7.0 版中) 開始,以及 OLE DB 和 ADO 都支援 Unicode 並採用 UCS-2 編碼機制。因此,如果應用程式與 Unicode 相容,當您完全都使用 SQL Server 執行個體的 Unicode 資料時,將沒有轉換的問題。如果用戶端使用 Unicode 相容的 API,但是資料儲存機制在 SQL Server 執行個體中不是 Unicode,就不會有轉換的問題。然而,如果有任何字元的字碼指標無法對應至 SQL Server 字碼頁,資料插入或更新作業將有損毀的可能性。
Unicode 最佳作法
決定是否要將非 DBCS 資料儲存成 Unicode ,通常是根據對於儲存效果的認知,以及排序、轉換和在與資料互動時發生資料損毀的可能性來判斷。排序和轉換的發生位置有可能會影響效能。然而,對於大部份的應用程式而言,這個影響是可以忽略的。具有設計精良的索引之資料庫,是不太可能受到影響的。然而,資料損毀不只是影響應用程式和資料庫的完整性而已,也會影響整個企業的運作。請考慮此折衷方案,如果下列兩者為真的話,在特定字碼頁排序字元資料就算是合理的:
由於硬體限制之故,轉換儲存空間是一個問題。或是,您經常需執行大量資料的排序,而測試顯示出 Unicode 儲存機制嚴重影響效能。
您非常確定所有存取此資料的用戶端其字碼頁都與您的字碼頁相符,而且此情況不會無預警變更。
很多時候,決定以 Unicode 儲存字元資料,甚至是非 DBCS 資料,都應該多加依據商業需求而非效能來決定。在今日網際網路流量快速成長下所帶動的全球經濟裏,支援在不同地區執行的用戶端電腦變得愈來愈重要。除此之外,想要挑選單一字碼頁來支援全球讀者所需的所有字元,也變得愈來愈困難。