たとえば、次のクエリは正常に機能します。
SELECT *
FROM quotes
WHERE expires_at <= '2010-10-15 10:00:00';
しかし、これは明らかに「文字列」比較を実行しています-特に「日時」比較を行うMySQLに組み込まれた関数があるかどうか疑問に思いました。
たとえば、次のクエリは正常に機能します。
SELECT *
FROM quotes
WHERE expires_at <= '2010-10-15 10:00:00';
しかし、これは明らかに「文字列」比較を実行しています-特に「日時」比較を行うMySQLに組み込まれた関数があるかどうか疑問に思いました。
...これは明らかに「文字列」比較を実行しています
いいえ-日付/時刻の形式がサポートされている形式と一致する場合、MySQLは暗黙的な変換を実行して、比較対象の列に基づいて値をDATETIMEに変換します。同じことが起こります:
WHERE int_column = '1'
int_column
...ここで、のデータ型はCHAR / VARCHAR / TEXTではなくINTであるため、「1」の文字列値はINTegerに変換されます。
文字列を明示的にDATETIMEに変換する場合は、STR_TO_DATE関数が最適です。
WHERE expires_at <= STR_TO_DATE('2010-10-15 10:00:00', '%Y-%m-%d %H:%i:%s')
しかし、これは明らかに「文字列」比較を実行しています
いいえ。文字列は自動的にDATETIME値にキャストされます。
11.2を参照してください。式の評価における型変換。
演算子が異なるタイプのオペランドで使用される場合、オペランドを互換性のあるものにするために型変換が行われます。一部の変換は暗黙的に発生します。たとえば、MySQLは必要に応じて数値を文字列に自動的に変換し、その逆も同様です。
私はそれがかなり古いことを知っていますが、私はちょうど問題に遭遇し、SQLドキュメントで見たものがあります:
[日付または時刻の値でBETWEENを使用する場合に最良の結果を得るには、] CAST()を使用して、値を目的のデータ型に明示的に変換します。例:DATETIMEを2つのDATE値と比較する場合は、DATE値をDATETIME値に変換します。DATEとの比較で「2001-1-1」などの文字列定数を使用する場合は、文字列をDATEにキャストします。
STR_TO_DATEを使用する方が良いと思います。なぜなら、そのためだけに関数を作成するのに時間がかかり、BETWEENドキュメントでこれを見つけたという事実もあるからです...