1

MySQL 5.1 に問題があります。日時データ型は、日付列と一致するように暗黙的にキャストされません。

 SELECT * FROM my_table WHERE my_date_field = NOW()

このリクエストは、MySQL 5.1 を使用して行を返しませんが、バージョン 5.0 ではうまく機能します。CURDATE()代わりに使用するNOW()と、MySQL 5.0 と MySQL 5.1 の両方で機能します。キャストが明示的 ( CAST(NOW() AS DATE)) の場合、MySQL 5.0 と MySQL 5.1 の両方で機能します。

この問題は、datetime から date への暗黙的なキャストでのみ発生します。この問題に既に遭遇した人や、この問題を解決する方法についての手がかりを持っている人はいませんか? CURTIME() の代わりに NOW() を使用するのが最善ではないことはわかっていますが、これはここでの問題ではありません。現在アプリケーションで使用されており、その目的はすべてを書き換えないようにすることです。

ありがとう！

4

3 に答える 3

3

これはMySQL 5.1.17で修正され、DATE カラムに格納されたときに CURDATE() が NOW() よりも小さい値に評価されるようになりました。

現在、DATE を DATETIME と比較すると、DATETIME として比較されます。DATE が DATETIME にキャストされると、時刻はゼロになります。

my_date_fieldが'2010-01-01'ANDNOW()である場合'2010-01-01 05:01:01'、それらを比較すると、my_date_fieldは に昇格しますが'2010-01-01 00:00:00'、これは明らかに よりも小さいです'2010-01-01 05:01:01'。

もともと、左側が列の場合、DATE から DATETIME への昇格は発生しませんでした。しかし、どうやら彼らは常にそれを宣伝する方が一貫性があると考えていた.

申し訳ありませんが、以前は機能していたことが幸運でした。時間がゼロの日付は、時間がゼロ以外の同じ日付よりも小さいと評価される必要があります。

残念ながら、この「バグ修正」を無効にする方法はありません。唯一の解決策は、NOW() を CURDATE() に変更するか、以前のバージョンにロールバックすることです。

実際には、独自のバージョンをコンパイルして、「バグ修正」を元に戻すか、NOW() 関数をオーバーライドすることができます。

于 2010-04-27T18:21:10.873 に答える
1

NOW()は typeDATETIMEでありCURDATE()、 type であるため、動作は理にかなっていDATEます。

変数が 1 つのサーバー バージョンでキャストされ、他のサーバー バージョンではキャストされない理由については、これはサーバー モードの違いのように思えます。つまり、キャストが失敗する 1 つのインスタンスが他のバージョンよりも厳密です。

そのドキュメントの興味深い点 (これがあなたの問題かどうかはわかりませんが、問題になる可能性があります): ALLOW_INVALID_DATES :

このモードは MySQL 5.0.2 で実装されています。5.0.2 より前では、これがデフォルトの MySQL 日付処理モードでした。5.0.2 の時点で、サーバーは月と日の値がそれぞれ 1 から 12 と 1 から 31 の範囲だけでなく、正当であることを要求します。厳密モードを無効にすると、「2004-04-31」などの無効な日付が「0000-00-00」に変換され、警告が生成されます。厳格モードを有効にすると、無効な日付によってエラーが生成されます。そのような日付を許可するには、ALLOW_INVALID_DATES を有効にします。

とにかく、変更ログを掘り下げて、何がいつ変更されたかを調べようとすることに意味があるかどうかはわかりません。私は両方の状況で動作するようにする傾向があり (つまり、あなたのことを正しく理解している場合は を使用しますCURDATE())、それで完了します。

于 2010-04-27T17:29:38.613 に答える
0

datetime 列の日付部分のみを比較します。

SELECT * FROM my_table WHERE DATE(my_date_field) = DATE(NOW())
于 2010-04-27T17:31:45.047 に答える