explicit_defaults_for_timestamp引起的狗血劇情

今天就碰到了一個較初級的問題，竟然爲找這個參數花了好半天時間，深覺得不齒。
需求是這樣的，有個表的某個字段須要從datetime改爲timestamp類型。原結構以下：
create table tmp1(
id int primary key auto_increment,
`gmt_create` datetime DEFAULT NULL COMMENT '建立時間'
)
修改語句：
alter table tmp1 modify gmt_create timestamp DEFAULT NULL COMMENT '建立時間'
報錯信息：
ERROR 1067 (42000): Invalid default value for 'gmt_approved'

原來是由於：
explicit_defaults_for_timestamp=0,表示使用默認的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=1，則關閉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，若是歷史數據多的化，這樣的轉化是很是耗資源的。同時還需考慮值的轉變對業務帶來的影響。