Unicode 的儲存和效能效果

SQL Server 使用 UCS-2 編碼配置儲存 Unicode 資料。在此機制下，所有的 Unicode 字元都使用 2 個位元組來儲存。

儲存 Unicode 與非 Unicode 字元資料的差異在於非 Unicode 資料是否使用雙位元組字集來儲存。所有的非東亞語言與泰文均以單位元組來儲存非 Unicode 字元。因此，將這些語言儲存為 Unicode 將需使用兩倍的空間來指定非 Unicode 字碼頁。另一方面，許多其他亞洲語言的非 Unicode 字碼頁都指定以雙位元組字集 (DBCS) 來儲存字元。因此，對於這些語言而言，不論以非 Unicode 或 Unicode 儲存幾乎都沒有差別。

下表顯示指定以雙位元組字集儲存字元資料的非 Unicode 字碼頁。

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 字碼頁，資料插入或更新作業將有損毀的可能性。