這是一個有趣的想法。SQL查詢中與時間相關的函數執行
UPDATE table1
SET field1 = UNIX_TIMESTAMP()
WHERE
field1 <= UNIX_TIMESTAMP() - 600
AND field2 > UNIX_TIMESTAMP() - 1000
將三個時間戳可能導致不同的價值觀..或者如果有機會,MySQL可能智能一次評估這些並將結果在所有這三個?
這是一個有趣的想法。SQL查詢中與時間相關的函數執行
UPDATE table1
SET field1 = UNIX_TIMESTAMP()
WHERE
field1 <= UNIX_TIMESTAMP() - 600
AND field2 > UNIX_TIMESTAMP() - 1000
將三個時間戳可能導致不同的價值觀..或者如果有機會,MySQL可能智能一次評估這些並將結果在所有這三個?
有趣的是,這沒有妥善記錄在UNIX_TIMESTAMP()
。對於NOW()
,在documentation是相當清楚的:
NOW()
返回一個恆定的時間點指出了 語句開始執行的時間。 (在存儲的函數或觸發器中,NOW()返回函數或觸發語句 開始執行的時間。)這與SYSDATE()
的行爲不同,返回執行的確切時間。
我認爲UNIX_TIMETAMP()
遵循相同的規則,NOW()
,但我不是100%肯定。
我想你不想重複unix_timestamp()。
SET @now = NOW();
UPDATE table1
SET field1 = @now
WHERE
field1 <= @now - 600
AND field2 > @now - 1000;
如果MySQL有可能智能地評估這些數據並在所有這三個數據中使用結果。我出於好奇而測試過它。在查詢中調用'UNIX_TIMESTAMP()'** 5030 **次,並花費** 206 **秒,結果都一樣。 – 1000111