3

次のテーブルに対して、SQL Server 2008 R2 で単純なクエリを実行しています。

Id (int、null 以外)
Enabled (ビット、null 以外)

両方の列に個別のインデックスがあります。

したがって、次のクエリを実行すると:

SELECT Id FROM Entities WHERE Enabled = 1

実行計画は、INDEX_SCAN が完了したことを示しています (これは、Enabled 列の CONVERT_IMPLICIT が原因です)。

そして、別のクエリを実行すると:

SELECT Id FROM Entities WHERE Enabled = '1'

また

SELECT Id FROM Entities WHERE Enabled = 'true'

また

SELECT Id FROM Entities WHERE Enabled = CAST(1 AS BIT)

実行計画は、INDEX_SEEK が完了したことを示しています。

CONVERT_IMPLICIT はより複雑なクエリのパフォーマンスに影響を与える可能性があるため、SQL Server がそのように動作する原因を知りたいですか?

更新:

私が走れば

SELECT Id FROM Entities WHERE Enabled = 0

その後

SELECT Id FROM Entities WHERE Enabled = 1

実行計画はINDEX_SEEKを示しています。この場合、SQL Server はいくつかの最適化統計を収集し、最終的に CONVERT_IMPLICIT の理由がないことを学習したと思います。しかし残念なことに、最初のクエリが反対の値で実行されることを保証することはできません。

私が得ることができる明確化に満足します。

4

1 に答える 1

3

2000 互換モードでデータベースを使用していますか? ここで読んだように、この互換モードを使用すると、この「問題」が発生しますが、2005 または 2008 の互換モードでは発生しません。

したがって、2000 互換モードを使用する必要がある場合は、「= '1'」比較を使用して CONVERT_IMPLICIT を回避する必要があります。これは、bit と int (または tiny int) の間の型の優先順位により、ビットを「アップグレード」する必要があるためです。 intに。

于 2012-08-31T12:00:45.027 に答える