2013-10-31 13 views
6

dateフィールドに基づいて行を返します。datetimeフィールドに相当します。彼らは明らかにdd/MM/yyyy = dd/MM/yyyy 00:00:00のフォーマットで直接一致するだけですが、私は時間を無視して探しています。SQLサーバーの日付と日時の等価性の比較

私が試した3つの方法がありますが、すべて動作しますが、何が最善であるか疑問に思っています。

1からCONVERT(varchar(10),MyDate,103) = CONVERT(varchar(10),MyDateTime,103))

2 - MyDate = CONVERT(date,MyDateTime)

3からMyDate = CAST(MyDateTime AS date)

4 - 私にMyDate = DATEADD(dd, DATEDIFF(dd, 0, MyDateTime), 0)

、#1は、確実に文字列比較を使用して文字列に変換し、最も遅くなければなりません効率が最も悪いはずです。しかし、テストではこれが最速です!以下私のテストである:

1 - 303ms平均

2 - 284ms平均

3 - 273ms平均

4 - 1745ms平均

テスト〜300,000サンプルサイズからのものです

これには理由がありますか?最初の選択肢は真に最良の選択肢ですか?

EDIT:300kレコードでそれぞれ10回実行されたテストを反映するようにテスト値を変更しました。結果を変更して、すべてが下に述べたDATEADD/DATEDIFFメソッドのTim Schmelterとかなり似ていることを示します。それははるかに効率的ではないようです。

+2

私は 'DATEADD/DATEDIFF'アプローチを使用しています。 http://stackoverflow.com/questions/1177449/best-approach-to-remove-time-part-of-datetime-in-sql-server –

+0

クローズリクエストに関して、私はこれが重複しているとは思わないなぜなら、この種の問題は、もう一つの問題の解決策に逆らっているからです。ここでは文字列の変換が最も速いです! 'DATEADD/DATEDIFF'を考慮した編集質問 – anothershrubery

+1

この平均のベースとなるサンプルサイズは? –

答えて

4

私は#3が最善の選択だと言います。ここに私の理由があります。

あなたはすでにパフォーマンス作業を行っていますので、私はそれをやり直しません。更新された数字はオプション1〜3を非常によく似ているので、#4を除外する以外はパフォーマンスを脇に置くことができます。

パフォーマンスが安定したら、ベストプラクティスと読みやすいようにします。 #1は、ほとんどのコードには間違いなく、読みにくいので、私はそれを排除します。この同じ理由は、すでに除外されている#4にも当てはまります。

これは#2と#3を残します。 CASTはSQL標準の一部であり、CONVERTより移植性が高いため、私の選択は#3になります。ですから、CONVERTの特別な機能を必要としないときはいつでも、常にCASTを使うことをお勧めします。

+1

これに加えて、関数内にフィールドをラップすると、それはsargeableになりません。つまり、インデックスがあればそれを使用することはできません。これは#3の別の正当な理由です。 –

+0

@ Nick.McDermaidは 'CAST'関数ではありませんか? –

+0

@Salman投稿からは明らかではありませんが、 'MyDate'はカラムであり、' MyDateTime'はカラムではありません。 –

1

MyDateがパラメータである場合、5番目のオプションがあります:MyDateTime[MyDate, MyDate + 1 DAY)の間にある場合

チェック。その列に索引がある場合、この照会は索引走査の代わりに索引探索を使用できます。

DECLARE @MyDate1 AS DATETIME = '2015-01-01'    -- 2015-01-01 00:00:00 
DECLARE @MyDate2 AS DATETIME = DATEADD(DAY, 1, @MyDate1) -- 2015-01-02 00:00:00 
SELECT ... WHERE MyDateTime >= @MyDate1 AND MyDateTime < @MyDate2