マットが示したフロアフロート変換を見たことがなかったことを認めなければなりません。私はこれをテストしなければなりませんでした。
私は純粋な選択（日付と時刻を返しますが、私たちが望むものではありません）、ここでの支配的な解決策（floor-float）、ここで言及されている一般的な「ナイーブ」なもの（stringconvert）、およびここで言及されているものをテストしました使用している（私が思ったように最速だった）
最大メモリ（32ビット、つまり約3.5 Gb）で実行されているXeon3GHzCPUを搭載したWin2003SP2サーバーで実行されているテストサーバーMSSQLServer2005でクエリをテストしました。私がいる夜なので、マシンはほとんど無負荷でアイドリングしています。私はそれをすべて自分で持っています。
これは、ミリ秒レベルまで変化するタイムスタンプを含む大きなテーブルから選択したテスト実行のログです。この特定のデータセットには、2。5年を超える日付が含まれています。テーブル自体には1億3000万行を超える行があるため、上位100万行に制限します。
SELECT TOP 1000000 CRETS FROM tblMeasureLogv2
SELECT TOP 1000000 CAST(FLOOR(CAST(CRETS AS FLOAT)) AS DATETIME) FROM tblMeasureLogv2
SELECT TOP 1000000 CONVERT(DATETIME, CONVERT(VARCHAR(10), CRETS, 120) , 120) FROM tblMeasureLogv2
SELECT TOP 1000000 DATEADD(DAY, DATEDIFF(DAY, 0, CRETS), 0) FROM tblMeasureLogv2
SQL Serverの解析およびコンパイル時間：CPU時間=0ミリ秒、経過時間=1ミリ秒。
（影響を受ける1000000行）テーブル'tblMeasureLogv2'。スキャンカウント1、論理読み取り4752、物理読み取り0、先読み読み取り0、lob論理読み取り0、lob物理読み取り0、lob先読み読み取り0。
SQL Serverの実行時間：CPU時間=422ミリ秒、経過時間=33803ミリ秒。
（影響を受ける1000000行）テーブル'tblMeasureLogv2'。スキャンカウント1、論理読み取り4752、物理読み取り0、先読み読み取り0、lob論理読み取り0、lob物理読み取り0、lob先読み読み取り0。
SQL Serverの実行時間：CPU時間=625ミリ秒、経過時間=33545ミリ秒。
（影響を受ける1000000行）テーブル'tblMeasureLogv2'。スキャンカウント1、論理読み取り4752、物理読み取り0、先読み読み取り0、lob論理読み取り0、lob物理読み取り0、lob先読み読み取り0。
SQL Serverの実行時間：CPU時間=1953ミリ秒、経過時間=33843ミリ秒。
（影響を受ける1000000行）テーブル'tblMeasureLogv2'。スキャンカウント1、論理読み取り4752、物理読み取り0、先読み読み取り0、lob論理読み取り0、lob物理読み取り0、lob先読み読み取り0。
SQL Serverの実行時間：CPU時間=531ミリ秒、経過時間=33440ミリ秒。 SQL Serverの解析およびコンパイル時間：CPU時間=0ミリ秒、経過時間=1ミリ秒。
SQL Serverの実行時間：CPU時間=0ミリ秒、経過時間=1ミリ秒。
ここで何を見ているのですか？
CPU時間（変換を調べています）に注目してみましょう。次の数値があることがわかります。
Pure-Select: 422
Floor-cast: 625
String-conv: 1953
DateAdd: 531
このことから、DateAdd（少なくともこの特定のケースでは）はフロアキャスト方式よりもわずかに高速であるように見えます。
そこに行く前に、クエリの順序を変更して、同じような結果でこのテストを数回実行しました。
これは私のサーバーで何か奇妙なことですか、それとも何ですか？