当前位置: 澳门新濠3559 > 数据库 > 正文

timestamp字段默认存在default,因此5.6.5之后DATETIM

时间:2019-11-03 13:48来源:数据库
现阶段最新的Mysql8.0 +Navicat12,使用中常常有局地老大难难点 澳门新濠3559,这两日有二个关于MySQL版本晋级的事,涉及到有个别有关时间项指标细节难题亟需考察,因而到官方网址找到

现阶段最新的Mysql8.0 + Navicat12,使用中常常有局地老大难难点

澳门新濠3559,这两日有二个关于MySQL版本晋级的事,涉及到有个别有关时间项指标细节难题亟需考察,因而到官方网址找到有关随笔,翻出来相比较便于本人通晓,博客这里也贴一下。

MySQL案例之Timestamp和Datetime,timestampdatetime

mysql数据库常用的日子档案的次序有timestamp和datetime,两个根本差别是挤占存款和储蓄空间尺寸不雷同、可存款和储蓄的时光也可能有限定,但针对分歧版本下,timestamp字段类型的装置要求郑重,因为无所谓的或是会被“坑死”。

风姿洒脱、TIMESTAMP和DATETIME字段类型相比

字段类型 存储长度 时间范围 备注
timestamp 4字节 '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC  
datetime 8字节(5.7占5字节) '1000-01-01 00:00:00' to '9999-12-31 23:59:59'  

 

timestamp字段默认存在default,因此5.6.5之后DATETIME也实现了这个功能。 

 

1.timestamp注意事项

(1)5.7版本在此之前,未有explicit_defaults_for_timestamp 参数(5.7私下认可开启,timestamp不会安装default值属性),timestamp字段暗许存在default CUMuranoRENT_TIMESTAMP on update CURRENT_TIMESTAMP属性,暗许值针对的基本点是以下函数爆发的时日

These are CURRENT_TIMESTAMP(), NOW(), LOCALTIME, LOCALTIME(), LOCALTIMESTAMP, and LOCALTIMESTAMP().

(2)mysql的timestamp值自动从当前时区转变成utc时区存款和储蓄,况兼自动从utc时区调换为日前系统时区检索重回

官方参考文档:https://dev.mysql.com/doc/refman/5.7/en/datetime.html

MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. 
(This does not occur for other types such as DATETIME.) By default, the current time zone for each connection is the server's time. 

2.datetime注意事项:

在mysql5.7从此,datetime字段也能够钦定默许值,况兼格式和timestamp同样

CREATE TABLE t1 (
  ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  dt DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
或
DEFAULT 0 or DEFAULT '2000-01-01 00:00:00'

二、数据库时区参数

1.system_time_zone

  数据库实例运营,从my.cnf配置参数timezone=timezone_name获取,若my.cnf未设置则从操作系统获取情状变量TZ获取
2.time_zone

  数据库当前其实利用的时区,默以为system,即系统时区,其设置能够通过set global time_zone=''设置,在这之中参数值有以下三种样式:'SYSTEM' 、'+10:00' 、'Europe/Helsinki'

Linux时区知识扩展:
Linux将时钟分为系统时钟(System Clock)和硬件(Real Time Clock,简称RTC)时钟两种。系统时间是指当前Linux Kernel中的时钟,
而硬件时钟则是主板上由电池供电的那个主板硬件时钟,这个时钟可以在BIOS的"Standard BIOS Feture"项中进行设置。
系统时钟:
    所有操作系统命令、函数依赖的时钟,独立于硬件时钟运行,可通过date设置
    设置系统时间:date -s "2017-08-22 22:58:00" 
    查看时区:date -R

硬件时钟:
    Linux启动从系统配置获取
    查看硬件时钟:clock --show  、 hwclock --show
    设置硬件时钟:hwclock/clock --set --date="月/日/年  时:分:秒"
    系统时钟同步到硬件:/sbin/clock -w
    硬件时钟同步到系统:/sbin/clock -s

时区设置:
    修改/etc/sysconfig/clock  
    ZONE=Asia/Shanghai
    rm /etc/localtime
    链接到上海时区文件   
    ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
    执行完上述过程后,重启机器,即可看到时区已经更改。                    

、实际行使实例

1.不一致版本下timestamp和datetime使用实例

(1卡塔 尔(阿拉伯语:قطر‎测量试验timestamp和datetime创建带暗中认可值的表
况兼实施成立带暗中同意值的SQL语句,开掘5.6(不含5.6卡塔 尔(阿拉伯语:قطر‎从前版本datetime不帮助带DEFAULT CUENVISIONRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

CREATE TABLE test (
  ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  dt DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

5.0.67版本
ERROR 1067 (42000): Invalid default value for 'dt'

5.5.20版本
ERROR 1067 (42000): Invalid default value for 'dt'

5.6.22版本
Query OK, 0 rows affected (0.02 sec)

5.7.18版本
Query OK, 0 rows affected (0.00 sec)

(2卡塔尔国测量试验timestamp和datetime创建表结构类型

不钦命私下认可值的景况下创办表结构,开掘5.6(不含5.6卡塔 尔(英语:State of Qatar)timestamp暗中同意值是CU奥迪Q5RENT_TIMESTAMP并且随着记录更新而立异

CREATE TABLE test01 (
  ts TIMESTAMP  ,
  dt DATETIME 
);

5.0.67版本
 CREATE TABLE `test01` (
  `ts` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
  `dt` datetime default NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1

5.5.20版本
 CREATE TABLE `test01` (
  `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `dt` datetime DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

5.6.22版本
CREATE TABLE `test01` (
  `ts` timestamp NULL DEFAULT NULL,
  `dt` datetime DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8

5.7.18版本
CREATE TABLE `test01` (
  `ts` timestamp NULL DEFAULT NULL,
  `dt` datetime DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8

(3卡塔 尔(阿拉伯语:قطر‎、测量试验timestamp和datetime类型mysqldump导出导入影响

测量检验结论为,timestamp数据类型的记录导出会以utc时间格式导出,导入库中自行由UTC格式转为系统暗中认可时区,所以见到导出文件timestamp内容时间戳和实际存储的不切合。

意气风发旦须求见到和导入与实际切合的日子戳,必要投入参数--tz-utc=false用于幸免timestamp时区转变,暗中认可是展开的,即导出文件中开首设置的/*!40103 SET TIME_ZONE='+00:00' */;

系统默许是cst时区,数据库参数设置也是CST和SYSTEM,按照系统时间插入数据:

| system_time_zone | CST    |
| time_zone              | SYSTEM |

insert into test01 values(sysdate(),sysdate());

5.0.67版本
select * from test01;
+---------------------+---------------------+
| ts                  | dt                  |
+---------------------+---------------------+
| 2018-01-12 14:15:19 | 2018-01-12 14:15:19 | 
+---------------------+---------------------+

5.5.20版本
select * from test01;
+---------------------+---------------------+
| ts                  | dt                  |
+---------------------+---------------------+
| 2018-01-12 14:15:27 | 2018-01-12 14:15:27 |
+---------------------+---------------------+

5.6.22版本
select * from test01;
+---------------------+---------------------+
| ts                  | dt                  |
+---------------------+---------------------+
| 2018-01-07 20:13:22 | 2018-01-07 20:13:22 |
+---------------------+---------------------+

5.7.18版本
select * from test01;
+---------------------+---------------------+
| ts                  | dt                  |
+---------------------+---------------------+
| 2018-01-07 20:13:20 | 2018-01-07 20:13:20 |
+---------------------+---------------------+

然后将数据库表test01表利用mysqldump导出

mysqldump dbtest --tables test01  >test01.sql
5.0.67版本
-- MySQL dump 10.11
--
-- Host: localhost    Database: dbtest
-- ------------------------------------------------------
-- Server version       5.0.67-percona-highperf-log
/*!40103 SET @[email protected]@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
--
-- Table structure for table `test01`
--
DROP TABLE IF EXISTS `test01`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `test01` (
  `ts` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
  `dt` datetime default NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;
--
-- Dumping data for table `test01`
--
LOCK TABLES `test01` WRITE;
/*!40000 ALTER TABLE `test01` DISABLE KEYS */;
INSERT INTO `test01` VALUES ('2018-01-12 06:15:19','2018-01-12 14:15:19');
/*!40000 ALTER TABLE `test01` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET [email protected]_TIME_ZONE */;
-- Dump completed on 2018-01-12  6:22:25 
5.5.20版本
-- MySQL dump 10.13  Distrib 5.5.20, for Linux (x86_64)
--
-- Host: localhost    Database: dbtest
-- ------------------------------------------------------
-- Server version       5.5.20-rel24.1-log

/*!40101 SET NAMES utf8 */;
/*!40103 SET @[email protected]@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
--
-- Table structure for table `test01`
--
DROP TABLE IF EXISTS `test01`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `test01` (
  `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `dt` datetime DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `test01`
--
LOCK TABLES `test01` WRITE;
/*!40000 ALTER TABLE `test01` DISABLE KEYS */;
INSERT INTO `test01` VALUES ('2018-01-12 06:15:27','2018-01-12 14:15:27');
/*!40000 ALTER TABLE `test01` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET [email protected]_TIME_ZONE */;
-- Dump completed on 2018-01-12 14:22:32
5.6.22版本
-- MySQL dump 10.13  Distrib 5.6.22-71.0, for Linux (x86_64)
--
-- Host: localhost    Database: dbtest
-- ------------------------------------------------------
-- Server version       5.6.22-71.0-log
/*!40101 SET NAMES utf8 */;
/*!40103 SET @[email protected]@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
--
-- Table structure for table `test01`
--
DROP TABLE IF EXISTS `test01`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `test01` (
  `ts` timestamp NULL DEFAULT NULL,
  `dt` datetime DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `test01`
--
LOCK TABLES `test01` WRITE;
/*!40000 ALTER TABLE `test01` DISABLE KEYS */;
INSERT INTO `test01` VALUES ('2018-01-07 12:13:22','2018-01-07 20:13:22');
/*!40000 ALTER TABLE `test01` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET [email protected]_TIME_ZONE */;
-- Dump completed on 2018-01-07 20:20:29
5.7.18版本
-- MySQL dump 10.13  Distrib 5.7.18-15, for Linux (x86_64)
--
-- Host: localhost    Database: dbtest
-- ------------------------------------------------------
-- Server version       5.7.18-15-log

/*!40101 SET NAMES utf8 */;
/*!40103 SET @[email protected]@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
--
-- Table structure for table `test01`
--
DROP TABLE IF EXISTS `test01`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `test01` (
  `ts` timestamp NULL DEFAULT NULL,
  `dt` datetime DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;
--
-- Dumping data for table `test01`
--
LOCK TABLES `test01` WRITE;
/*!40000 ALTER TABLE `test01` DISABLE KEYS */;
INSERT INTO `test01` VALUES ('2018-01-07 12:13:20','2018-01-07 20:13:20');
/*!40000 ALTER TABLE `test01` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET [email protected]_TIME_ZONE */;
-- Dump completed on 2018-01-07 20:20:29

剔除test01表,并用mysqldump导出文件还原

mysql -D dbtest -e "drop tables test01"
mysql -D dbtest  <test01.sql 
select * from test01;

5.0.67版本
+---------------------+---------------------+
| ts                  | dt                  |
+---------------------+---------------------+
| 2018-01-12 14:15:19 | 2018-01-12 14:15:19 | 
+---------------------+---------------------+
5.5.20版本
+---------------------+---------------------+
| ts                  | dt                  |
+---------------------+---------------------+
| 2018-01-12 14:15:27 | 2018-01-12 14:15:27 |
+---------------------+---------------------+
5.6.22版本
+---------------------+---------------------+
| ts                  | dt                  |
+---------------------+---------------------+
| 2018-01-07 20:13:22 | 2018-01-07 20:13:22 |
+---------------------+---------------------+
5.7.18版本
+---------------------+---------------------+
| ts                  | dt                  |
+---------------------+---------------------+
| 2018-01-07 20:13:20 | 2018-01-07 20:13:20 |
+---------------------+---------------------+

(4)ON UPDATE CURRENT_TIMESTAMP属性影响

生机勃勃旦带有ON UPDATE CU路虎极光RENT_TIMESTAMP属性,则只要对表记录更新,此记录对应的timestamp类型记录也会更新

ts字段是timestamp类型且含有on update current_timestamp属性,dt字段是datetime类型且不含on update current_timestamp属性
更新前:
mysql -D dbtest -e "select * from test01;"
+---------------------+---------------------+------+
| ts                  | dt                  | id   |
+---------------------+---------------------+------+
| 2018-01-12 14:15:19 | 2018-01-12 14:15:19 | NULL | 
+---------------------+---------------------+------+
更新:
mysql -D dbtest -e "update test01 set id=1 where id is null"
更新后:
mysql -D dbtest -e "select * from test01;"                  
Logging to file '/home/mysql/query.log'
+---------------------+---------------------+------+
| ts                  | dt                  | id   |
+---------------------+---------------------+------+
| 2018-01-12 15:42:15 | 2018-01-12 14:15:19 |    1 | 
+---------------------+---------------------+------+

2.例外版本下mysqldump截止时间解析

应用mysqldump备份的同人都或然会静心到,符合规律备份结束以来,在文件结尾会有一条成功甘休的代表,即 :-- Dump completed on 2018-01-12  6:22:25。

其生机勃勃在mysql5.0后能够经过有些参数调整,比方能够加参数--comments=false来幸免增多comments音信,即怀有--初步的comment会不记录在备份文件中,也可以扩大--dump-date=false来幸免时间戳增多,即只含有-- Dump completed。

但特意要求注意的是,这时候间戳的原由在mysqldump 10.11版本(mysql5.0.x版本对应MySQL dump 10.11, 含10.11本子卡塔 尔(英语:State of Qatar)记录的是UTC时区时间戳,而在mysqldump 10.12本子之后(mysql 5.5一倡百和的本子是MySQL dump 10.13,含10.13卡塔尔国记录的是系统当下时区时间戳。

故而大家看看的是mysqldump 10.11备份甘休的时光总是比系统当下日子提前8钟头,举个例子mysql5.0体系当下是CST时区:2018-01-12  14:22:25   而备份文件停止时间戳是-- Dump completed on 2018-01-12  6:22:25。这几个只是记录的岁月戳差异,不影响最终的多寡记录时间。

源码片段如下:

./client/mysqldump.c

#define DUMP_VERSION "10.13"

static void write_footer(FILE *sql_file)
{
  if (opt_xml)
  {
    fputs("</mysqldump>n", sql_file);
    check_io(sql_file);
  }
  else if (!opt_compact)
  {
    if (opt_tz_utc)
      fprintf(sql_file,"/*!40103 SET [email protected]_TIME_ZONE */;n");

    fprintf(sql_file,"n/*!40101 SET [email protected]_SQL_MODE */;n");
    if (!path)
    {
      fprintf(md_result_file,"
/*!40014 SET [email protected]_FOREIGN_KEY_CHECKS */;n
/*!40014 SET [email protected]_UNIQUE_CHECKS */;n");
    }
    if (opt_set_charset)
      fprintf(sql_file,
"/*!40101 SET [email protected]_CHARACTER_SET_CLIENT */;n"
"/*!40101 SET [email protected]_CHARACTER_SET_RESULTS */;n"
"/*!40101 SET [email protected]_COLLATION_CONNECTION */;n");
    fprintf(sql_file,
            "/*!40111 SET [email protected]_SQL_NOTES */;n");
    fputs("n", sql_file);

    if (opt_dump_date)
    {
      char time_str[20];
      get_date(time_str, GETDATE_DATE_TIME, 0);
      print_comment(sql_file, 0, "-- Dump completed on %sn", time_str);
    }
    else
      print_comment(sql_file, 0, "-- Dump completedn");

    check_io(sql_file);
  }
} /* write_footer */

 

mysql数据库常用的年华项目有timestamp和datetime,两个根本不一致是据有存款和储蓄空间尺寸区别等、可存款和储蓄...

消除了的都会贴出来,收益于小友大家

参谋官方网站网址:

大家的对象是发掘标题,化解难点,迎接大家贴出自身行使时相遇的标题,博采有益的意见

好了,上干货!(努力续更中。。。卡塔 尔(阿拉伯语:قطر‎

一、简介


自MySQL 5.6.5发端TIMESTAMP和DATETIME类型可以完结全自动起先化或更新为CULX570RENT_TIMESTAMP的成效,在5.6.5事先那么些性格只有TIMESTAMP技巧用。

 

出于今后岁月档期的顺序基本都用DATETIME(因为TIMESTAMP的约束超级小局限性也相当的大卡塔尔,由此5.6.5今后DATETIME也兑现了那几个意义。

配备使用日志

以此效果详细描述下正是:

问题一:

  • DATETIME也足以像TIMESTAMP相像将CUPAJERORENT_TIMESTAMP设为暗中同意值
  • 假定你为那时间列设置了自动更新的性子,那么只要一条记下的此外任何列值产生更动,时间列都会自动更新为CULANDRENT_TIMESTAMP。

设置达成后,重要义务就是能三番五次的上

只要你不想让设置自动更新属性的日子列随其余列值的改变而改变,你可认为他显式的赋叁个值。

Navicat12 连接不上 MySQL8.0,总是报错1251;

TIMESTAMP类型:

原因是MySQL8.0版本的加密方法和MySQL5.0的不相仿,连接会报错。

  • 在8.0.2版本在此之前,借使您定义了这么叁个列:ts timestamp [not null] default xxx,那么除非您显式的给此列赋二个非NULL的值,不然意气风发律插入的眼下时刻戳,无论你的default值设置的是怎样,你能够将其视为贰个BUG。你能够经过将explicit_defaults_for_timestamp设置为ON来制止那么些处境。
  • 在8.0.2本子以前,假诺你定义了多少个ts timestamp [not null]列,但未曾设置暗中认可值,那么真相上那几个列是ts  timestamp not null default current_timestamp on update current_timestamp,同样的您能够因此设置explicit_defaults_for_timestamp为ON来消除此难点。
  • 当explicit_defaults_for_timestamp为OFF时,除非内定timestamp可为NULL,不然MySQL自动为timestamp设置not null属性。

解决:修正加密方法为mysql_native_password

在5.6.5事先,以上timestamp的表现能够算是他相比datetime的四个优势,也可能有人把它视为三个BUG认为他很麻烦,但不管如何在5.6.5事先要是您有将CU福睿斯RENT_TIMESTAMP设为暗中同意值的急需,那您不能不选拔timestamp类型,幸好5.6.5今后datetime也扶持了。

alter user 'root'@'localhost' identified with mysql_native_password by '(密码)';

关于explicit_defaults_for_timestamp参数:

 

在MySQL5.6.6引入了explicit_defaults_for_timestamp参数来解决上述timestamp暗中同意值的标题(此参数在8.0.1事先的版本暗许是OFF,只读参数卡塔 尔(英语:State of Qatar),而在MySQL8.0.2自此此参数暗许值变为ON并且能够在线纠正。将此参数设为ON后你为timestamp列设置的默许值就足以生效了。


从这里能够看出explicit_defaults_for_timestamp=on的功能就是,使得你协调为timestamp列设置的default值生效,当您未设置暗许值和自立异时MySQL也不会自作主见的为not null时间列增加current_timestamp和on update current_timestamp的暗中认可选项。

 

除此以外此参数在8.0.1第11中学提醒已经要稳步弃用了。

意义接纳日志

 

作用需求:

二、怎样设置时间列(本文如无版本号提醒,示例统一是MySQL5.6的条件卡塔 尔(英语:State of Qatar)

程序导入一条通知记录时,数据库自动记录当今日子

借使您要设置一个自行伊始化+自动更新为CULANDRENT_TIMESTAMP的时日列(TIMESTAMP or DATETIME卡塔尔国,那么使用“DEFAULT CU奥迪Q5RENT_TIMESTAMP”+“ON UPDATE CURRENT_TIMESTAMP”的组成,定义的各种不留意,可替代CUKoleosRENT_TIMESTAMP的显要字有:CU昂科威RENT_TIMESTAMP(), NOW(), LOCALTIME, LOCALTIME(), LOCALTIMESTAMP, 以及LOCALTIMESTAMP()。

澳门新濠3559 1

官方网站详细的列出了大概现身的默许值+自动更新选项的组合:

谬误现象:

1)

前后相继导入一条文告记录时,私下认可时间为空

CREATE TABLE t1 (
ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
dt DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP);

澳门新濠3559 2

2)

解除方法:

CREATE TABLE t1 (
ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
dt DATETIME DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE t1 (
ts TIMESTAMP DEFAULT 0,
dt DATETIME DEFAULT 0
);

navicate12 版本中,字段为timestamp的设置时,私下认可的安装为null,且在12版本中,暗中同意值选拔项中一贯不CUMorganPlus 4RENT_TIMESTAMP,需手动键入,如下:

3)

澳门新濠3559 3

CREATE TABLE t1 (
ts TIMESTAMP DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP,
dt DATETIME DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP
);

手动修正timestamp的私下认可值为CU福特ExplorerRENT_TIMESTAMP后,亲测有效贯彻效果与利益必要。

4卡塔 尔(英语:State of Qatar)自立异的timestamp列假诺未安装私下认可值且未鲜明钦命可为NULL,则暗中认可值为0,0代表0000-00-00 00:00:00。

 

CREATE TABLE t1 (
ts1 TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, -- default 0
ts2 TIMESTAMP NULL ON UPDATE CURRENT_TIMESTAMP -- default NULL
);
CREATE TABLE t1 (
dt1 DATETIME ON UPDATE CURRENT_TIMESTAMP, -- default NULL
dt2 DATETIME NOT NULL ON UPDATE CURRENT_TIMESTAMP -- default 0
);

    自创新的DATETIME列假诺未设置暗中认可值且定义了not null,那么暗中认可值为0。

5)

CREATE TABLE t1 (
ts1 TIMESTAMP DEFAULT 0,
ts2 TIMESTAMP DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP);
CREATE TABLE t2 (
ts1 TIMESTAMP NULL,
ts2 TIMESTAMP DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP);
CREATE TABLE t3 (
ts1 TIMESTAMP NULL DEFAULT 0,
ts2 TIMESTAMP DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP);

对于此次成立的3个表:

  • 3个表的第多个timestamp列都不曾机关开首化和自动更新的属性。(自动伊始化是指调用的系统时间函数卡塔 尔(英语:State of Qatar)
  • 3个表的差距在于ts1列对NULL值的拍卖,t1.ts1非空,当你为他赋值为NULL时插入的莫过于是当前时间戳,t2.ts1,t3.ts1允许null值,由此当您插入NULL时最终被插入的正是NULL。
  • t2和t3对于ts1的暗许值管理也不生龙活虎致,t2.ts1同意null值且未定义暗中认可值,因而默许值正是NULL,t3.ts1允许null值且定义了default 0,由此暗许值就是0。

编辑:数据库 本文来源:timestamp字段默认存在default,因此5.6.5之后DATETIM

关键词:

  • 上一篇:没有了
  • 下一篇:没有了