Unicode のストレージとパフォーマンスの影響
SQL Server 2005 では、UCS-2 エンコード体系を使用して Unicode データが格納されます。このメカニズムでは、2 バイトを使用してすべての Unicode 文字が格納されます。
Unicode 文字データと Unicode 以外の文字データを格納する際の違いは、Unicode 以外のデータが 2 バイト文字セットを使用して格納されているかどうかに依存します。東アジア以外のすべての言語およびタイ語では、Unicode 以外の文字は 1 バイトで格納されます。したがって、これらの言語を Unicode として格納すると、Unicode 以外のコード ページを指定したときに使用される領域の 2 倍の領域が使用されます。一方、他の多くのアジア言語の Unicode 以外のコード ページでは、2 バイト文字セット (DBCS) の文字格納領域が指定されます。そのため、これらの言語では、Unicode 以外で使用する領域と Unicode で使用する領域には、ほとんど違いがありません。
次の表は、2 バイト文字セットの文字データ格納領域が指定された、Unicode 以外のコード ページを示しています。
| 言語 | コード ページ |
|---|---|
中国語 (簡体字) |
936 |
中国語 (繁体字) |
950 |
日本語 |
932 |
韓国語 |
949 |
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 コード ページにマップできない文字を指している場合に、そのデータの挿入操作や更新操作によりデータが破損するリスクがあります。
Unicode の推奨事項
DBCS 以外のデータを Unicode として格納するかどうかの判断は、一般的に、ストレージへの影響があるかどうか、およびクライアントによるデータの操作中に、並べ替えや変換がどの程度行われ、データ破損の可能性がどの程度あるかによって決まります。並べ替えおよび変換は、パフォーマンスに影響する場合があります。その影響は、並べ替えや変換が行われた場所によって異なります。ただし、多くのアプリケーションでは、パフォーマンスの影響はごくわずかです。特に、インデックスが適切に作成されたデータベースは、影響を受ける可能性が低くなります。しかし、データの破損はアプリケーションおよびデータベースの整合性だけでなく、ビジネス全体にも影響します。このトレードオフを考慮して、次の両方の項目に当てはまる場合に、特定のコード ページに文字データを格納することを検討するようにしてください。
- ハードウェアの制限により、ストレージ領域の節約が問題になっている。または、大量のデータの並べ替えを頻繁に実行することがあり、テストによって Unicode による格納方式がパフォーマンスに大きく影響していることが示されている。
- このデータにアクセスするすべてのクライアントのコード ページが、自分のコード ページに一致することがわかっていて、この状況が予期せず変更されることがない。
ほとんどの場合、文字データが DBCS のデータでなくても、そのデータを Unicode で格納することに決定した場合、その決定はパフォーマンスではなく、ビジネスのニーズに基づくものです。インターネット トラフィックの急速な成長によって経済活動がグローバルに広がる中、異なるロケールで実行されるクライアント コンピュータをサポートする重要性は高まっています。また、世界中のユーザーが必要とするすべての文字をサポートするコード ページを 1 つだけ選択することはますます難しくなっています。