web-dev-qa-db-ja.com

SQL Server 2019 UTF-8サポートの利点

社内フォーラムソフトウェアでCOMPRESS()とDECOMPRESS()を使用することに慣れていますが（現在はSQL Server 2017です）、データベースをできる限り効率的にしようとしています。 SQL Server 2019への将来の移行時に_UTF-8のようにLatin1_General_100_CI_AS_SC_UTF8を現在の照合に追加することには利点がありますか？

sql-servercollationencodingutf-8
3
John Titor

これは、ここ：

可変長エンコーディングであるUTF-8エンコーディングは、一部のシナリオでは大きなメリットになる可能性がありますが、状況によっては状況が悪化することもあります。残念ながら、データ圧縮とクラスター化列ストアインデックスがSQL Serverのすべてのエディションで利用可能であることを考えると、「_ UTF8」エンコーディングの使用はほとんどありません。 UTF-8エンコーディングの真のメリットがある唯一のシナリオは、次の条件がすべて当てはまる場合です。

  1. データはほとんどが標準ですASCII（値0 – 127）ですが、少量のさまざまなUnicode文字が含まれている、または含まれている可能性があります（単一の8-ビットコードページ、または8ビットコードページには存在しない場合があります）。
  2. 列は現在（またはそうでなければ）NVARCHAR（MAX）です（つまり、データはNVARCHAR（4000）に収まりません）。
  3. この列または列のセットには多くのデータがあります（NVARCHARに格納されている場合は1 GB以上）。
  4. テーブルをクラスター化列ストアテーブルにすると、パフォーマンスに悪影響が及ぶ（テーブルの使用方法により）ORデータは通常8000バイト未満です。列をVARBINARY（MAX）にする必要はありません） 、COMPRESS（）をINSERTおよびUPDATE操作に使用し、DECOMPRESS（）をSELECTクエリに使用します（VARBINARY値は、インデックス化できないMAXデータであるため、VARBINARY値をインデックス化できないことを心配する必要はありません）。 Gzip圧縮された値は、文字列のUTF-8バージョンよりもはるかに小さくなりますが、値をフィルタリング（「=」外）または操作する前に解凍する必要があります。
  5. バックアップのサイズを減らし、バックアップと復元にかか​​る時間を減らし、バッファプールへの影響を減らすことの利点は、クエリのパフォーマンスに悪影響を与える可能性のあるコスト（CPUと経過時間の両方）を上回ります。ここでは、バックアップ圧縮（EnterpriseおよびStandard Editionで利用可能）が役立つ場合があることに注意してください。

HTMLページの保存は、この説明に当てはまるシナリオの良い例です。もちろん、UTF-8は、最も一般的な文字に最小限のスペースを使用しながら、Unicode文字の全範囲を許可しているため、インターウェブの推奨エンコーディングです。

4
Outman

データベースをできるだけ効率的にしよう

ここで実際に機能している効率には、少なくとも2つの異なるタイプがあります。

  1. スペース（ディスクとメモリ）
  2. 速度

特定の条件下では（その回答の上部にリンクされている私のブログ投稿の「推奨される使用方法/ガイダンス」セクションのコピー/貼り付けであるOutmanの回答で説明されているように）、スペースを節約できますが、それは完全にタイプと行ごとの文字数。

ただし、少なくとも現在の実装では、速度が減少する可能性が高くなります。これは、内部でのUTF-8データの処理方法が原因である可能性があります。 UTF-8データを非UTF-8 VARCHARデータと比較すると、両方の値がUTF-16 LE（つまりNVARCHAR）に変換されることを知っています。 Windows/SQL Server/.NETが常にUnicodeを処理していたため、UTF-8データをNVARCHARに変換するために他の（おそらくほとんどの）操作が必要になったとしても、私は驚かないでしょう。

したがって、UTF-8を使用することでメリットが得られる可能性のあるシナリオがあると仮定すると、どちらの効率がより重要かを選択する必要があります。

現在、UTF-8が環境自体が本来UTF-8（Linuxなど）であるシナリオにメリットがあるかどうかはまだ不明です。通常、データベースドライバー（ODBC、SQL Native Clientなど）は、クライアントとサーバー間の変換を処理します。ここでパフォーマンス/効率が向上する可能性があると思いますifこれを行うと、ドライバーソフトウェアが必要な追加の手順（およびCPUサイクル）をスキップしますそれらのエンコーディング変換を行います。これまでのところ、私はテストしていないため、これは単なる理論です。

次の点に注意してください。

  1. UTF-8は、実装を容易にするためにASCII互換性を実現するように設計されました。これにより、標準ASCIIベースのシステムが許可されます（値0〜127、値128〜255が拡張されますASCIIこれでカバーされていません）新しいエンコーディングで何も再保存せずにUnicodeを有効にします。

    SQL Serverの目標は、現在VARCHARを使用している既存のアプリが、多くの再コーディング（つまり、文字列リテラルにNプレフィックスを追加）したり、 VARCHARからNVARCHARへ。

    これは、圧縮形式として設計されたではありません。 UTF-8でフットプリントが削減されたデータがある場合は、すばらしいです。しかし、標準ASCII以外のデータを処理する場合、節約効果がないか、さらに悪い場合は、UTF-8に移動してデータサイズを増やすことができます（65kのうち63k BMP文字は、UTF-8で3バイト、つまり、UTF-16で必要な2バイトよりも1バイト多くです。

    また、UTF-8によってパフォーマンスが向上する場合、または少なくともパフォーマンスの低下が見られない場合は、すばらしいです。しかし、それを期待しないでください。実際、パフォーマンスが低下したとしても驚かないでください。

  2. SQL ServerでUTF-8照合を実装する場合は、いくつかの潜在的なデータの「問題」に注意する必要があります。

    1. UTF-8文字列リテラルや変数（現在のデータベースにはUTF-8のデフォルト照合があるため）と非UTF-8 VARCHARcolumns。これは、照合の優先順位により、照合がUTF-16から列が使用しているコードページに効果的にダウングレードされるためです。
    2. UTF-8以外の文字列リテラルや変数とUTF-8列（および場合によっては変数）を混在させることによる小さな切り捨て。これは、UTF-8で元のエンコーディングよりも多くのバイトを必要とする特定の文字が原因です。
    3. UTF-8の無効なバイトシーケンスは、デフォルトの置換文字「�」を返す代わりにエラーをスローする可能性があります。これは、他の8ビットエンコーディングまたはUTF-16で無効なシーケンスを使用してこれまで行われてきたアプローチとは異なります。

    詳細と例については、私の投稿の「心に留めておくべきこと：運用」セクションを参照してください： SQL Server 2019のネイティブUTF-8サポート：救世主か偽預言者か

6
Solomon Rutzky