次のような2つのテーブルがあるとします。
Events
ID (PK int autoInc), Time (datetime), Caption (varchar)
Position
ID (PK int autoinc), Time (datetime), Easting (float), Northing (float)
Time
たとえば、参加基準としてフィールドを使用している場合、すべてのイベントとその位置をリストしても安全ですか? すなわち:
SELECT E.*,P.* FROM Events E JOIN Position P ON E.Time = P.Time
または、単に datetime 値を比較するだけでも (パラメータ化された値に秒の小数部が含まれている可能性があることを考慮してください - MySQL は常にこれを受け入れています)。
SELECT E.* FROM Events E WHERE E.Time = @Time
MySQL (バージョン 5.6.4 より前) は、ミリ秒を含まない日時フィールドのみを格納することを理解しています。したがって、このクエリは問題なく機能すると思います。ただし、バージョン 5.6.4 の時点で、MySQL が日時フィールドにミリ秒を格納できるようになったことを読みました。
などの関数を使用して datetime 値が挿入されると仮定するとNOW()
、ミリ秒が切り捨てられ (<5.6.4)、上記のクエリが機能すると想定されます。ただし、バージョン 5.6.4 以降では、これが機能しない可能性があります。私はそうであり、2 番目の精度に関心があるのはこれからだけです。
誰かが次の質問に答えることができれば、大歓迎です:
- 一般に、MySQL はどのように日時フィールドを相互に比較しますか (上記のクエリを検討してください)。
- 上記のクエリは問題なく、時間フィールドのインデックスを利用していますか? (MySQL < 5.6.4)
- ミリ秒を除外する方法はありますか? つまり、挿入時および条件付き結合/選択などで?(MySQL > 5.6.4)
- 上記の結合クエリは機能しますか? (MySQL > 5.6.4)
編集
私は日時をキャストできることを知っています。答えてくれた人たちに感謝しますが、ここで問題の根本に取り組もうとしています(ストレージタイプ/定義が変更されたという事実)。クエリ。これにより、すべてのクエリを書き直す必要があることは言うまでもなく、インデックスなどを適用してクエリを最適化するという私のすべての作業が無効になります。
EDIT2
DATETIME
2 番目の精度を使用して、フィールドに参加しない理由を提案できる人はいますか?