MySql的CURRENT_TIMESTAMP
在创建时间字段的时候
DEFAULT CURRENT_TIMESTAMP
表示当插入数据的时候,该字段默认值为当前时间
ON UPDATE CURRENT_TIMESTAMP
表示每次更新这条数据的时候,该字段都会更新成当前时间
这两个操作是mysql数据库本身在维护,所以可以根据这个特性来生成【创建时间】和【更新时间】两个字段,且不需要代码来维护
如下:
CREATE TABLE `mytest` (
`text` varchar(255) DEFAULT '' COMMENT '内容',
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间'
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
可以通过navicat的可视化界面直接操作
- 优点:省事,开发的时候不用去考虑更新的时间
- 缺点:增加数据库服务的开销,开启事务事件后插入时间的不准确性。
- 问题描述
- mysql中对于UPDATE_TIME字段我们有时候会设置ON UPDATE CURRENT_TIMESTAMP,表示在数据库数据有更新的时候UPDATE_TIME的时间会自动更新(如果数据库数据值没有变化的话,UPDATE_TIME是不会自动更新的)。那么假设一个场景,我们有一个长事务有10秒,在进入事务第2秒的时候我们执行了一个update操作,然后往下继续执行,直到第10秒,事务提交。此时数据库记录的时间是执行update的时候的第2秒的时间点呢?还是事务提交后的第10秒的时间点?
- 验证结果
事务提交完成后,保存到数据库的时间是执行update的第2秒的时间点。 - 场景限制
如果UPDATE_TIME只是用来记录更新时间,那么这个自动更新的时间点倒是没有什么影响。但是如果想要用UPDATE_TIME来作为数据同步(比如同步到另一个库,或者es之类的)的依据,那么就不能够这样定义。因为我们使用UPDATE_TIME作为更新,一般也是要求准实时同步,假如一个事务比较长,在事务还没提交过程中我们已经记录了更新的时间,等事务提交后,这个UPDATE_TIME的时间我们是没有同步到的。举个栗子:
一个长事务的开始时间为12:00:00,结束时间为12:00:10,
在12:00:02的时候执行了update操作,此时数据库的UPDATE_TIME的时间还是12:00:00,因为事务还没提交。
与此同时有个定时任务在扫描这段时间内的数据,比如12:00:00到12:00:03,没有数据,因此将12:00:03记录下来,下次从这个时间点继续往后扫描,等12:00:10时长事务提交,此时数据库中该条数据的UPDATE_TIME值为12:00:02,但是定时任务扫描不会再扫描中这条数据了,就会导致同步数据不完整。对这种情况,我们只能够在程序中进行设置UPDATE_TIME的值,而不应该通过数据库本身设置ON UPDATE CURRENT_TIMESTAMP