ITPub博客

首页 > 数据库 > MySQL > MySQL案例-TIMESTAMP NOT NULL与NULL

MySQL案例-TIMESTAMP NOT NULL与NULL

原创 MySQL 作者:wangwenan6 时间:2017-08-31 10:59:51 0 删除 编辑
-------------------------------------------------------------------------------------------------短文---------------------------------------------------------------------------------------------------------------
场景:
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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2014-02-28

  • 博文量
    102
  • 访问量
    1388048