首頁  >  文章  >  資料庫  >  實例分享之MySQL 8.0 timestamp引發的問題

實例分享之MySQL 8.0 timestamp引發的問題

WBOY
WBOY轉載
2022-01-17 15:44:332463瀏覽

這篇文章為大家帶來了mysql中關於字段預設值可能會出現的相關問題,希望對大家有幫助。

實例分享之MySQL 8.0 timestamp引發的問題

今天業務回饋了一個問題,modify_time欄位不允許為null,而業務回饋這個欄位是設定了預設值的,具體的業務報錯資訊如下所示:

實例分享之MySQL 8.0 timestamp引發的問題

從報錯訊息看,可能是modify_time欄位沒有設定預設值或預設值設定的不正確導致

接下來查看一下表格結構:

CREATE TABLE `jj_xxxx` (
....
  `create_time` timestamp NOT NULL DEFAULT '1999-12-31 23:00:00' ,
  `update_user` int DEFAULT NULL,
  `modify_time` timestamp NOT NULL DEFAULT '1999-12-31 23:00:00',
 ....
  PRIMARY KEY (`goods_id`)
) ENGINE=InnoDB AUTO_INCREMENT=4893 DEFAULT CHARSET=utf8 COMMENT='xxxxx'

從表結構看,設定的預設值好像也沒有啥問題,檢查一下sql_mode參數的設置,好像也沒有發現啥問題;

業務人員回授線上的表也是這樣的,但是線上是正常的,而目前要把這個業務遷移到其他的環境,從業務到資料庫是另外一套環境;

忽然考慮到了資料庫版本的差異;遷移的新環境是MySQL 8.0版本,而線上環境是5.7版本,兩個版本中參數explicit_defaults_for_timestamp 設置的默認值是不一樣的;

原因:

explicit_defaults_for_timestamp 系統變量決定MySQL服務端對timestamp列中的預設值和NULL值的不同處理方法。

此變數自MySQL 5.6.6 版本引入,分為全域級別和會話級別,可動態更新,預設值為OFF。

在8.0之中預設值改為on

explicit_defaults_for_timestamp=OFF,表示使用預設的timestamp預設格式;timestamp類型的預設格式是什麼樣的呢?

1、和其它字段類型不一樣,這個字段預設為not null.而且不允許設置default null.

2、第一列timestamp字段,如果不強制指定預設值或on update屬性的話,就會預設設為DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP。

3、非第一列timestamp字段,如果不強制指定預設值,DEFAULT '0000-00-00 00:00:00'

4、往該列插入null值,會自動轉換為預設值;

explicit_defaults_for_timestamp=ON,則關閉timestamp default的特性:

##1、如果沒有被顯示指定not null,則預設為null;

2、預設值也會是null而非CURRENT_TIMESTAMP;

3、如果指定了not null屬性,inset式不指定該欄位的值,strict sql_mode下,會報錯。非strict sql_mode下插入'0000-00-00 00:00:00';

需要仔細考慮下面的場景:

1、timestamp not null default CURRENT_TIMESTAMP ,當explicit_defaults_for_timestamp由0轉為1時會帶來什麼業務影響?

這樣的轉化,如果該timestamp欄位有預設值,會造成原本insert 該timestamp欄位value為null的語句會插入失敗,影響業務;

2、datetime default null 轉成timestamp default CURRENT_TIMESTAMP,又會帶來什麼業務影響?

做這樣的欄位轉化,會把原本該欄位為null的值都轉換成CURRENT_TIMESTAMP,如果歷史資料多的化,這樣的轉換是非常耗資源的。同時也需考慮數值的轉變對業務帶來的影響。

推薦學習:

mysql影片教學#

以上是實例分享之MySQL 8.0 timestamp引發的問題的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文轉載於:Mysql技术公众号。如有侵權,請聯絡admin@php.cn刪除