MySQL タイムスタンプ比較クエリで遭遇する落とし穴と解決策

タイムスタンプ比較クエリで遭遇する落とし穴

JD.com では、テーブルを作成するときに、MySQL で update_time を timestamp として設定し、create_time を datetime として設定する必要があったことを覚えています。その後、Alibaba のコーディング標準では、両方とも datetime 型である必要があると規定されました。

タイムスタンプと日付時刻の違いは、さまざまな場所で紹介されています。 JD.com では、なぜ update_time をタイムスタンプにする必要があるのか​​疑問に思うことがあります。場所を取らないからでしょうか？または、タイムスタンプのデフォルト値を設定することしかできませんか (current_timestamp の更新時)?デフォルト値のdatetimeも設定できないのでしょうか？後で Baidu で検索したところ、デフォルト値を設定するための datetime サポートは 5.7 でのみ利用可能であることがわかりました。 JD.com にこのような要件があるのは、以前使用されていた MySQL のバージョンが低すぎたため、update_time を自動的に更新する必要もあったためかもしれません。

現在、企業でもこれが求められており、update_time はタイムスタンプに設定されています。その結果、落とし穴に遭遇しました。同僚が非常に奇妙な問題を発見しました。日付比較クエリには結果がないのに、ログに出力された SQL を直接実行すると結果をクエリできるのはなぜでしょうか? ?なぜこのような矛盾が生じるのでしょうか? これまでにこのようなことは一度もありませんでした。問題を解決するのはいつも楽しいことです。

実際に現地で試してみましたが、確かにそうでした。印刷されたログに問題はありませんでしたが、私たちを「混乱」させ、非常に奇妙な気分にさせたのはログでした。確認したところ、比較されているフィールドはタイムスタンプ型の update_time であることがわかりました。 Alibabaの基準に影響されて、これはタイプの問題だと痛感しました。そこでBaiduで検索してみたところ、タイムゾーンの問題であることがわかりました。データベース接続 URL の後に serverTimezone=GMT%2B8 パラメータを追加するだけです。もちろん、別の方法としては datetime を使用することですが、これにより多くの落とし穴を回避できます。

なぜこの問題が発生するのでしょうか?これは、アプリケーション サーバーと MySQL がデプロイされているサーバーのタイム ゾーンが一致していないためです。このため、印刷ログには問題がないのに、クエリ結果が表示されません (ログに表示される時間はローカル マシンのタイム ゾーンですが、データが MySQL サーバーに転送されると、別のタイム ゾーンの時間になります)。

MySQL の日付にもこの問題があります。 。 。

タイムスタンプクエリ範囲の問題

例えばMySQLでは、更新時刻が2020-05-26の場合、クエリはupdate_time <= 2020-05-26となり、見つけることができません。DATE_FORMAT(info.up_time,'%Y-%m-%d') <= '2020-05-26'に変換する必要があります。具体的な理由は不明であり、さらなる調査が必要です。

上記は私の個人的な経験です。参考になれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。