MySQL案例-TIMESTAMP NOT NULL與NULL

wangwenan6發表於2017-08-31
MySqlNull
-------------------------------------------------------------------------------------------------短文---------------------------------------------------------------------------------------------------------------
場景:
MySQL >= 5.7.17, 業務反饋資料庫版本升級到5.7以後, 以前的一些sql在新版本無法執行了;

結論:
版本變遷導致一些不規範的寫法被MySQL阻止了;

分析:
在測試環境重現一下;
新版本報錯的語句:

點選(此處)摺疊或開啟

  1. insert into timestamp_test values(0,null);

相關表的表結構:

點選(此處)摺疊或開啟

  1. CREATE TABLE `timestamp_test` (
  2.   `id` int(11) NOT NULL,
  3.   `time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  4.   PRIMARY KEY (`id`)
  5. ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

報錯資訊如下:


當然, 從表面上看, 這種做法肯定不行, 都已經宣告瞭time是not null的, 但是程式說老版本沒問題, 而這種做法又是必需的, so......_(:з」∠)_......let' go!

既然是timestamp的問題, 那就找找有關timestamp的data type相關的資訊吧;

翻一翻文件, 發現有這麼一章: Automatic Initialization and Updating for TIMESTAMP and DATETIME

仔細找了找, 發現有提到這個問題:

 
大致意思: 
如果explicit_defaults_for_timestamp這個選項處於關閉狀態, 那麼當timestamp(注意, 不是datetime)的列在更新時, 可以用null來作為SQL中的value,
MySQL會自動使用當前時間來進行替換;

貌似改個引數就能解決了?  (⊙_⊙)


試試先.....


額.....這應該是最近最好解決的問題了.....至於sql_mode, strict_mode什麼的對種行為毫無影響;

PS: 這個引數是和DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP一起使用的, 單獨使用應該是沒什麼效果;


PPPPPPS: 其實這個小問題沒必要寫個blog, 扔在"千奇百怪的MySQL"下的 "MySQL之奇奇怪怪的小問題"就好了, 不過嘛...居然還有這種操作....這是我看到這種做法的第一反應....(╯>д<)╯ 那就記下來吧.....

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29510932/viewspace-2144361/，如需轉載，請註明出處，否則將追究法律責任。

相關文章