SQL Server では異なるデータ型を使用して操作をする際に暗黙の型変換 (CONVERT_IMPLICIT) が発生することがあります。
データ型の変換 (データベース エンジン)
式の暗黙的なデータ型変換
少量のデータ操作であれば大きな影響は出てこないことがあるのですが、大量のデータ操作になるとこの暗黙の型変換の影響が処理速度に影響してくることがあります。
今回は実行プランから暗黙の型変換を調べるための方法について少しまとめてみたいと思います。
なお、暗黙の型変換について調べるときは SQL Server フォーラムの以下のスレッドがとても参考になります。
暗黙の型変換の影響
今回は 3 種類のテーブルを用意しています。
BaseTable は操作のベースとなるテーブルです。
今回は、そのテーブルから Inplicit / NonInplicit のテーブルに対してデータを挿入してみます。
BaseTable は int ですので bigint に対してデータを挿入する場合には、暗黙の型変換が発生するはずですね。
Inplicit / NonInplicit に対してデータを INSERT INTO SELECT で挿入した場合の実行プランがこちらになります。
int → bigint に挿入をした場合には、Compute Scalar というイテレータが表示されていることが確認できます。
このイテレータが存在している場合型変換が発生していることがあります。
# 計算により新しい列を作り出す操作ですので、暗黙の型変換以外でも発生します。
これだけでは本当に暗黙の型変換化はわかりませんので、プロパティや実行プランの XML の表示から詳細を確認してみます。
今回はプロパティから確認をしていますが、スカラー操作として [CONVERT_IMPLICIT] が行われていることが確認できます。
これが暗黙の型変換になります。
この操作が行われると、相手の方に合わせるために既存の列から新しい列が生成されます。
今回は int → bigint に変換がされていましたが int → nvarchar(max) に変換された場合はどうなるでしょう。
Implicit2 が nvarchar(max) で設定されているテーブルになるのですが、見た目はどちらの実行プランも同じになっていますね。
Compute Scalar から Table Insert に流れるデータのサイズを調べてみます。
nvarchar(max) に型変換された場合は、データの推定サイズが大幅に異なっていることが確認できます。
# 可変長サイズですので実際にこのサイズが流れるわけではないと思いますが。
この辺も暗黙の型変換が発生した場合に大きく影響してきます。
暗黙の型変換はオーバーヘッドですのでできるだけ発生がしないようにクエリやテーブルを設計するように心がけるようにしたいですね。