既に保存されているﾃﾞｰﾀには何ら影響はありません｡

ただ､処理の中で CURRENT_TIMESTAMP や now() を使ってﾃﾞｰﾀを挿入､更新しているところがあると､timestamp 型のｶﾗﾑでｿｰﾄした時に期待した順序ではなくなったり､unique 制約がある timestamp 型のｶﾗﾑで､現在時刻と全く同じ値を持つﾚｺｰﾄﾞが存在すると､ﾚｺｰﾄﾞの挿入に失敗する､という事はあるかもしれません｡

MySQL 自体は､あくまでも､言われたとおりにﾃﾞｰﾀを保存しているだけなので､timestamp 型に過去の時刻でも未来の時刻でも入れる事はできます｡MySQL に保存されているﾃﾞｰﾀが突然､別なﾃﾞｰﾀに変わる事はありません｡問題があるとすれば､そのﾃﾞｰﾀを扱うｱﾌﾟﾘｹｰｼｮﾝ側の問題です｡

時計を過去に戻した瞬間に､MySQL 側の動作自体に無いか影響が無いか､という事は考えたのですが､具体的に､こんな問題が起こる､という話は見つけられませんでした｡1年ほど前に､うるう秒の問題で MySQL がｽﾄｰﾙする現象が発生(原因は､Linux ｶｰﾈﾙ側の問題)した事はありますが､通常は問題ないはずです｡

実際の時間順と記録上の時間順が入れ替わってしまわないかという問題についてご心配でしょうか？

結論から言うと心配する必要はありません｡

• 狂うときは､徐々に進んでいくか徐々に遅れていくかですよね｡このときは､時間のずれが発生しているとは言え､時間順の狂いは発生していません｡
• 狂いを直すときです｡UNIXでもWindowsでも､ｻｰﾊﾞ用のOSは時間を直すとき､徐々に遅らすか徐々に進ます方法で時刻を修正します｡ですので時間順の狂いは発生しないようになっています｡

というわけで､時計に狂いのある状態では危険だからﾃﾞｰﾀを保存しない､などのような判断をする必要はないようになっています｡

>何らかの要因でｻｰﾊﾞｰ内のｼｽﾃﾑ時計が狂い過去の時間になってしまった場合

このような自体がそもそも発生してはいけません｡
なので，時刻情報が重要なｻｰﾊﾞには，時刻が狂わないようにntpﾃﾞｰﾓﾝを必ず入れておきます｡
これで問題となる状況自体を回避できます｡


>timestamp型など､どのような挙動になるのでしょうか
C：狂った時間で時刻が記録されます｡
R：狂う前の時間が読み取られます｡
U：狂った時刻で時刻が更新されます｡
D：普通に削除されます｡


>もし過去の時間になってしまった場合､MySQL側で対処しﾃﾞｰﾀを保存しないようにしたい

上述の通り，OS側ではNTPｻｰﾊﾞとの通信によって時刻の正当性を担保します｡

DB側で時刻の正当性を担保したい場合，
既存ﾚｺｰﾄﾞの中から最新の一件の情報をSELECTして，そこに記録されている時刻を見るという手があります｡
もしその時刻が未来だったら，ありえないﾚｺｰﾄﾞなわけで，ｼｽﾃﾑ時刻が狂って過去にさかのぼっていると判断できます｡
また，一定間隔でﾃｰﾌﾞﾙ内にﾚｺｰﾄﾞが記録されるとしたら，それらのﾚｺｰﾄﾞの記録時刻の間隔をﾁｪｯｸしてみるというのも一つの手です｡間隔が通常値でなければ，その時点でｼｽﾃﾑ時刻は狂ったのだと判断できます｡
でも，これらの手法はあんまり良い手ではありません｡

いずれにしても，DBはOS上で動く単なるｱﾌﾟﾘであり，
ｼｽﾃﾑ時刻を管理しているのはOSですから，
DBではなくOS側で別個に時刻の狂いを防御する機構を設けないといけません｡