DATETIME フィールドがあります。先週更新されたすべてのレコードを選択したいと思います。現在、私はこのクエリを使用しています：
SELECT SUM(mins_spent) as time_sum FROM todos WHERE
lastUpdate >= '2008-12-22' AND lastUpdate <='2008-12-28'
しかし、得られる結果は時間帯によって異なるようです。たとえば、午後 7 時は 17 時間、午後 11 時は 14 時間になりますが、減少ではなく増加するはずです。クエリを次のように変更することを考えていました。
SELECT SUM(mins_spent) as time_sum FROM todos WHERE
lastUpdate >= '2008-12-22 00:00:00' AND lastUpdate <='2008-12-28 00:00:00'
それはまったく役に立ちますか？提案してください..
'2008-12-22'等しいはず'2008-12-22 00:00:00'です。
「28日の終わりまで」をご希望ですか？その場合は、2 番目の日付に追加23:59:59します。
または、 を使用することもできますlastUpdate < "2008-12-29"。
既存の ToDo への変更をどのように追跡していますか? INSERTおよび/またはDELETE? それともUPDATE？
「完了」時にレコードを 'ing している場合DELETEは、レコードが少なくなります。
'ing' の場合UPDATE、現在の週を超えて日付を変更できますか? その場合、それらは結果から削除されます。
mins_spent何が起こっているかを確認するには、テーブル、、およびlastUpdate(値をマークダウンし、それらがどのように変化するかを確認するために時々実行します)でいくつかの集計を取得してみてください。
SELECT count(*) AS Total
FROM todos
WHERE lastUpdate >= '2008-12-22' AND lastUpdate <= '2008-12-28 23:59:59'
SELECT min(mins_spent) AS Min, max(mins_spent) AS Max, avg(mins_spent) AS Avg
FROM todos
WHERE lastUpdate >= '2008-12-22' AND lastUpdate <= '2008-12-28 23:59:59'
SELECT min(lastUpdate) AS Min, max(lastUpdate) AS Max
FROM todos
WHERE lastUpdate >= '2008-12-22' AND lastUpdate <= '2008-12-28 23:59:59'
MySQL 6.0 Reference Manual for Date and Time Typesから判断すると、書かれているとおりに多かれ少なかれ問題ないはずです。ただし、実際に機能しない場合は、報告可能なバグが見つかった可能性があります。
DATE 値は、時間部分を「00:00:00」として追加することにより、強制的に DATETIME 型になります。代わりに DATETIME 値の時刻部分を無視して比較を実行するには、CAST() 関数を使用して次の方法で比較を実行します。
date_col = CAST(NOW() as DATE);
あなたのクエリは '<= '2008-12-28'; と言います。これは、厳密には、以下ではなく、以下でなければなりません。
非常に細かい点の 1 つは次のとおりです。作成した式を DATETIME (LHS は DATETIME 列であるため) または DATE (RHS は DATE として扱うのが最適であるため) として処理するか、または実際に DATETIME を次のように変換しますかRHS に一致する文字列? LHS が DATE に変換されると違いが生じます。これは、21 日から 27 日までのすべてが必要なように見えるのに対し、28 日のいつでも範囲内になるためです。型をキャストで明示的に修正するとどうなりますか?
また、MySQL サーバーはあなたと同じタイムゾーンで実行されていますか? あなたが見ていたものと名目上の一日の終わりとの間に「1時間ごと」の違いがあるように見えましたか? それがどのように (誤って) 機能しているのかはまだ正確にはわかりませんが、それ以外の場合は説明されていない要因である可能性があります。