3

タイムスタンプの数学演算中にMySQLが何をしているのかを理解しようとしています。

結果として生じる問題の画像：

ここに画像の説明を入力してください

左側に開始と終了の2つのタイムスタンプがあり、開始から終了までの期間を見つける必要があるので、これを実行します。

終了-開始

私はいくつかの本当に奇妙な結果を得ていました。たった3時間の間に、その2〜3倍の量の結果が返ってきたことがわかります。

最初にUTCに変換すると、計算はうまくいきます。

左側のタイムスタンプでSQLが何をしているのか誰かが説明できますか？私は常に、すべてのタイムスタンプが内部でUTCであるという印象を受けてきました。そのため、min、max、lessなどは変換せずに機能します。

ありがとう！

コード：

select  
    min(timestamp) start, 
    max(timestamp) end, 
    max(timestamp) - min(timestamp) start_to_end, 
    unix_timestamp(min(timestamp)) startUTC, 
    unix_timestamp(max(timestamp)) endUTC,
    unix_timestamp(max(timestamp)) - unix_timestamp(min(timestamp)) start_to_end_UTC
from post_snapshots group by permalink;
4

3 に答える 3

1

これらの例は、タイムゾーンの変換とは関係ありません。一方の日付をもう一方の日付から直接減算すると、MySQLは既存のすべての日付部分から整数を生成し、数学演算を実行します。たとえば、次のクエリは次のとおりです。

select now()+1;

戻り値（ '2013-02-26 14:38:31' + 1）：

+----------------+
| now()+1        |
+----------------+
| 20130226143832 |
+----------------+

したがって、「2013-02-1916:49:21」と「2013-02-1919:07:31」の違いは次のようになります。

20130219190731 - 20130219164921 = 25810

この減算を取得する正しい方法は、日付をタイムスタンプに変換するか（実行したように）TIMESTAMPDIFF(SECOND, start_date, end_date)、8290を返すを使用することです。

于 2013-02-26T17:46:00.167 に答える
1

これは、DATETIMEvs TIMESTAMP。またはタイムゾーンの問題ではありません。

MySQLは、各値を数値に変換することにより、減算（またはその他の数学演算）のオペランドとして日時を処理しますが、これは秒数ではなく、日時の数字をまとめたものです。データから例を見てみましょう。

2013-02-19 16:49:21になります20130219164921

2013-02-19 19:07:31になります20130219190731

これら2つの数値の違いは...25810です。これは、減算演算の結果として表示される値です。あなたが指摘したように、それは数秒の結果ではありません。それは本当にあまり役に立たないという意味ではありません。

対照的に、TIMESTAMPDIFF()ソートをはるかに超えて重要な違いを探している場合は、実際には時間に適した計算を使用して違いを実行します（またはUnixタイムスタンプに事前変換します）。

SELECT TIMESTAMPDIFF(SECOND, '2013-02-19 16:49:21', '2013-02-19 19:07:31')
>>> 8290
于 2013-02-26T17:40:22.083 に答える
0

何が起こるかというと、mysqlで日付/日時を差し引くことはできません。すべての数学演算で、mysqlタイムスタンプデータ型は日時データ型のように動作します。代わりに使用できます

  select  
    TIMESTAMPDIFF(SECOND,min(timestamp),max(timestamp))
  from post_snapshots group by permalink;
于 2013-02-26T17:40:19.603 に答える