Unicode のストレージとパフォーマンスの影響

SQL Server では、UCS-2 エンコード体系を使用して Unicode データが格納されます。このメカニズムでは、2 バイトを使用してすべての Unicode 文字が格納されます。

Unicode 文字データと Unicode 以外の文字データを格納する際の違いは、Unicode 以外のデータが 2 バイト文字セットを使用して格納されているかどうかに依存します。東アジア以外のすべての言語およびタイ語では、Unicode 以外の文字は 1 バイトで格納されます。したがって、これらの言語を Unicode として格納すると、Unicode 以外のコード ページを指定したときに使用される領域の 2 倍の領域が使用されます。一方、他の多くのアジア言語の Unicode 以外のコード ページでは、2 バイト文字セット (DBCS) の文字格納領域が指定されます。そのため、これらの言語では、Unicode 以外で使用する領域と Unicode で使用する領域には、ほとんど違いがありません。

次の表は、2 バイト文字セットの文字データ格納領域が指定された、Unicode 以外のコード ページを示しています。

Unicode データのパフォーマンス上の影響は、次の項目を含むさまざまな要因によって複雑になります。

• Unicode の並べ替え規則と、Unicode 以外の並べ替え規則の違い

• 2 バイト文字の並べ替えと、1 バイト文字の並べ替えの違い

• クライアントとサーバー間でのコード ページの変換

SQL Server では、Windows 照合順序で定義された Unicode 以外のデータの文字列比較を実行するときに、Unicode の並べ替え規則を使用します。Unicode の並べ替え規則は Unicode 以外の並べ替え規則よりもはるかに複雑なので、リソースを集中的に消費します。そのため、Unicode の並べ替え規則は、多くの場合、コストが高くなりますが、Unicode データと Windows 照合順序で定義された Unicode 以外のデータでのパフォーマンスの差は通常はわずかです。

SQL Server で Unicode 以外の並べ替え規則が使用されるのは、SQL 照合順序を使用して定義された Unicode 以外のデータに対してのみです。この場合の並べ替えおよびスキャンは、Unicode の並べ替え規則が適用される場合よりも、通常は高速になります。Windows 照合順序または SQL 照合順序のいずれかを使用して定義された、Unicode の並べ替え規則がすべての Unicode データに適用されます。

次に重要なのは、大量の Unicode データを並べ替えると、Unicode 以外のデータの場合よりも並べ替え速度が遅くなる場合があることです。これは、データが 2 バイトで格納されるためです。一方、Unicode でアジア言語の文字を並べ替えると、並べ替え速度は特定のコード ページでアジア言語の DBCS データを並べ替えるよりも速くなります。これは、Unicode 文字が固定幅であるのに対し、DBCS データには実際には 1 バイトと 2 バイトの幅が混在しているためです。

パフォーマンスに関する他の問題は、主に SQL Server のインスタンスとクライアント間でのエンコード メカニズムの変換の問題によって決まります。通常、クライアントとサーバー間のコード ページの変換におけるパフォーマンスの影響はごくわずかです。それでも、この層で何が発生しているのかを理解することは重要です。

ODBC API のバージョン 3.6 以前、および DB-Library API では、Unicode は認識されません。これらの API によって定義されたデータ アクセス方法を使用するクライアントでは、Unicode データをクライアント コード ページに暗黙的に変換するためにリソースが使用されます。また、特定の Unicode 文字が認識されないクライアント コード ページの場合に、クライアント側でデータが破損するリスクがあります。

SQL Server Version 7.0 に含まれていた Microsoft Data Access Components Version 2.7 以降の ODBC のバージョン、および OLE DB と ADO は Unicode に対応しており、UCS-2 エンコード メカニズムを想定しています。したがって、アプリケーションが Unicode に対応している場合、SQL Server のインスタンスの Unicode データが厳密に扱われていれば変換の問題は発生しません。クライアントが Unicode 対応の API を使用していて、SQL Server のインスタンスのデータ格納方式が Unicode でない場合、変換の問題は発生しません。ただし、データの文字コードが SQL Server コード ページにマップできない文字を指している場合に、そのデータの挿入操作や更新操作によりデータが破損するリスクがあります。