1

全て、

(サーバー)時間間隔に依存するプロジェクトで時間を処理する方法を決定しようとしています(要するに、ユーザーが少なくともn時間前に特定のアクションを完了した後に一部のコンテンツが利用可能になります)。現時点では、Unix タイムスタンプを抽出しtime()て MySQL にそのまま保存するのが最も簡単な方法のようです。

これが良い考えではない理由はありますか?知っておく必要がある落とし穴はありますか?パフォーマンスへの影響は?

4

3 に答える 3

2

私には問題ないようです。ただし、UNIX のタイムスタンプDATETIMEや.DateTimetime()

$time = new DateTime;
echo $time->format("Y-m-d H:i:s"); //Outputs current time, example: 2012-10-13 22:58:34
于 2012-10-13T20:58:14.353 に答える
2

タイムスタンプは問題ありません。割らないでください、それは不要な計算です。タイムアウトを更新するよりも頻繁に (オブジェクトごとに) クエリを実行する予定がある場合は、現在の時間ではなく有効期限を保存することをお勧めします (デルタの計算は 1 回のみ)。DATETIME 列に注意してください: タイムゾーン設定は考慮されませんが、PHP は考慮されます... したがって、異なるリクエストで異なるタイムゾーン設定を使用している場合は、運が悪いです。タイムスタンプは絶対的なものであり、1:59 の 2 分後を 3:01 とする夏時間などの管理も考慮します...

于 2012-10-13T21:02:58.230 に答える
1

実はこれが一番のアイデアです。この関数time()は、1970 年 1 月 1 日 00:00:00 からの秒数を返します。のみであるため、パフォーマンスへの影響はありませんinteger。MySQL で、そのようなフィールドを作成しますINT, 10, Unsigned

時間があれば、SELECT と WHERE のパフォーマンスが向上します。http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with-myisam/を参照してください。

あなたが抱えている唯一の問題は、時間は2038年に限られています...しかし、2038年になるまでに、内部のコンピュータークロックバイトは大きくなります...そう願っています。

あなたがDATETIMEについて心配したいかもしれない他のことは、UTCの下で実行されるPHP time()ですが、DATETIMEはタイムゾーンに依存しています...

10000000 行で INSERT を実行したときの統計。

ここに画像の説明を入力

インデックスを使用して SELECT / WHERE を実行したときの統計:

ここに画像の説明を入力

于 2012-10-13T20:59:38.393 に答える