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，若是历史数据多的化，这样的转化是很是耗资源的。同时还需考虑值的转变对业务带来的影响。