Varchar はパフォーマンスに悪影響を与える可能性があります – Quan Mai のブログ

文字列はアプリケーションで最も一般的なデータ型であるため、 nvarchar とその亜種 varchar おそらく、データベース内で最も一般的な列タイプです。 (私たちはほとんどいつも使っています nvarchar なぜなら nchar これは、私たちが持っていない固定長の列を対象としています)。 違いは、 nvarchar エンコーディングは UTF-16/USC-2 ですが、 varchar UTF-8がある

SQL Server 2012 (11.x) 以降、 補助文字 (SC) 有効な照合順序が使用される場合、これらのデータ型には全範囲のデータが格納されます。 ユニコード 文字データを使用し、 UTF-16 文字コード。 非 SC 照合順序が指定されている場合、これらのデータ型には、サポートされている文字データのサブセットのみが格納されます。 UCS-2 文字コード。

しかし varchar 予期しない形で有害になる可能性があります。 2 つの列を持つこの単純なテーブルがあると仮定しましょう (命名を許してください。これ以上良い名前が思いつきません)。

CREATE TABLE [dbo].[Demo](
	[varcharColumn] [varchar](50) NULL,
	[nvarcharColumn] [nvarchar](50) NULL
)

それぞれに、ほぼ一意の同じランダム値が挿入されます。 これらの各列に非クラスター化インデックスを追加します。ご存知のとおり、インデックスはこれらの値に基づくクエリ実行において非常に効率的です。

アウトなしで試してみましょう varchar 最初のコラム。 それはかなりうまく機能するはずです。 いいえ！

SELECT *
  FROM dbo.[Demo]
  where varcharColumn = N'0002T9'

効率の高いインデックス シークの代わりに、テーブル全体に対してインデックス スキャンを実行します。 もちろん、これはあなたが望んでいることではありません。

しかし、なぜ？ 良い質問。 お気づきかもしれませんが、N’0002T9′ を使用しました。 nvarchar type – パラメータが文字列型の場合、.NET がクエリに渡すものです。 実行計画を詳しく見てみると、SQL Server が次のことを実行する必要があることがわかります。 CONVERT_IMPLICIT この列の各行で、事実上インデックスが無効になります。

ただし、何も考えずに ‘0002T9’ を渡すと、正常に動作します。これは、開発中に動作するため混乱を引き起こす可能性がありますが、デプロイされるとはるかに遅くなります。

違いを確認するには、クエリを並べて実行します。 これは 130,000 行の非常に単純なテーブルのものであることに注意してください。 数百万以上の行がある場合、その差はさらに大きくなります。

(1 row affected)
Table 'Demo'. Scan count 1, logical reads 4, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.


(1 row affected)
Table 'Demo'. Scan count 1, logical reads 422, physical reads 0, page server reads 0, read-ahead reads 14, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

その逆はどうなるのでしょうか？ 次のようなデータがある場合 nvarchar(100) ただし、パラメータは次のように渡されます varchar ? SQL Server はこれを簡単に処理できます。 パラメータを単に次のように変換します。 nvarchar そして、必要に応じてインデックスシークを実行します

それでこの話は道徳的ですか？ 使用する特別な理由がない限り、 varchar （または char ）、 続ける nvarchar （または nchar ) データベースのパフォーマンスに悪影響を与える可能性のあるデータ型変換の複雑さを回避するためです。