DATETIME与TIMESTAMP比较与使用

2019-02-16 09:07:11 MySQL

MySQL

DATETIME&TIMESTAMP

今天要给之前存在的表添加一个publish_time，然后之前记得一直都是习惯性的用TIMESTAMP来作为这种用MySQL自动添加时间字段的数据格式，DATETIME来作为其他一些记录时间的数据格式。看网上很多的文章，这里不得不吐槽一下，百度出来的前几条基本都是一样的，无非是换个人，换个网站，内容基本都是复制的第一个人的，试想一下：第一个人对某一个知识点认知有点偏差，那后来的人呢？单纯的听说，单纯的引用，不去自己实验是不推荐的。

就http://stackoverflow.com/questions/409286/should-i-use-field-datetime-or-timestamp这个网页上一些回答和一些评论，然后自己测试，得出以下拙见，如有不当，还请指正！

有一个观点是TIMESTAMP不能为NULL

我不信！于是我没忍住，手一抖建了个表

create table if not exists test_vv(
    id int(6) not null auto_increment primary key,
    word text
) engine = MyISAM default charset utf8;
# 添加一个字段ttime 类型是 TIMESTAMP
alter table test_vv add dtime datetime null;
alter table test_vv add ttime timestamp null;

你猜怎么着？没错，执行成功！也就是说是TIMESTAMP也是可以接受NULL值。所以，在这点上二者是没有区别的！

还有一个区别是时区改变对二者的影响

时区的改变对TIMESTAMP是有影响的，对DATETIME是没影响的。

mysql> select * from test_vv;
+----+------+---------------------+---------------------+
| id | word | dtime               | ttime               |
+----+------+---------------------+---------------------+
|  1 | test | 2017-01-18 02:23:07 | 2017-01-18 02:23:07 |
+----+------+---------------------+---------------------+
1 row in set (0.00 sec)

mysql> show global variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CST    |
| time_zone        | -08:00 |
+------------------+--------+
2 rows in set (0.00 sec)

mysql> set global time_zone='SYSTEM';
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql> show global variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CST    |
| time_zone        | SYSTEM |
+------------------+--------+
2 rows in set (0.00 sec)

mysql> select * from test_vv;
+----+------+---------------------+---------------------+
| id | word | dtime               | ttime               |
+----+------+---------------------+---------------------+
|  1 | test | 2017-01-18 02:23:07 | 2017-01-18 02:23:07 |
+----+------+---------------------+---------------------+
1 row in set (0.00 sec)

mysql> exit
Bye

mysql> select * from test_vv;
+----+------+---------------------+---------------------+
| id | word | dtime               | ttime               |
+----+------+---------------------+---------------------+
|  1 | test | 2017-01-18 02:23:07 | 2017-01-18 18:23:07 |
+----+------+---------------------+---------------------+
1 row in set (0.00 sec)

可以看到，在改变时区后，当前session下两者是一样不变的，为什么说是当前session，因为大家可以发现，我exit之后，重新连接数据库，再次查询，数据格式为TIMESTAMP的ttime是发生了改变的。也就是说时区改变会改变后续的session中TIMESTAMP类型数据，但是任何情况下DATETIME的是不变的。

二者区间的差别

还有一个比较是区间的比较，看有人说DATETIME：The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'.TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC.

这个我不清楚对不对，但是我把0000-00-00 00:00:00插入到两种数据格式的字段，是可以执行成功的。所以我不清楚是从什么纬度来规定二者范围的。如果真的是有范围的，那么生日很容易击中TIMESTAMP的下限，而类似银行贷款，或者保险的截止日期很容易击中TIMESTAMP的上限，而且到2038年也并不是很遥远了，在这种情况下，建议用DATETIME来记录这些比较固定的数据；TIMESTAMP用来记录数据的插入和变动情况。

其他

附：添加或者修改字段记录数据插入或者更新时间 SQL

#添加一列插入数据时createtime更新为当前时间
ALTER TABLE tablename ADD COLUMN createtime timestamp NULL DEFAULT CURRENT_TIMESTAMP;
#修改一列插入数据时createtime更新为当前时间，两种写法都可以
ALTER TABLE tablename MODIFY createtime timestamp  NULL DEFAULT CURRENT_TIMESTAMP;
ALTER TABLE tablename CHANGE createtime createtime timestamp  NULL DEFAULT CURRENT_TIMESTAMP;
#插入修改的时候createtime更新为当前操作时间，只要在后面加“ON UPDATE CURRENT_TIMESTAMP”， 即可，只举一例，其他相同
ALTER TABLE tablename ADD COLUMN createtime timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

然后，还通过把TIMESTAMP换成DATETIME发现，效果貌似是一样的，DATETIME也是可以实现的。不过要注意一点就是，数据“真”的变更才会更新时间。例如：name原来就是vien，然后你set name = 'vien'，这种情况下是不会更新时间的，而在set name = 'shavien' 这种情况下时间是会更新的。

欢迎小伙伴们在下方评论区留言 ~ O(∩_∩)O
文章对我有帮助, 点此请博主吃包辣条 ~ O(∩_∩)O

AdSense Anaconda Android apache API apt Auth AWS B-tree Bandwagon Blog bower brew bytes Caffe Catalina certbot Charles cloudcone Composer conda CoreML CPU crontab CSS csv Cuda cv2 datetime Digitalocean DNS Docker Docker-Compose Eloquent Excel export Flask FTP GET Git GitHub GitLab Gmail GoDaddy Google GTM hash Homebrew Homestead HTML http HTTPS IDEA image imagemagick imagick imgick import InnoDB ios iou iPhone ISO8601 iTerm2 Java JavaScript JPG JS Keras Laravel Laravel-Admin lazyload Linux list Livewire lnmp load logs Lravel Mac Markdown matplotlib md5 mix MobileNet Mojave mongo MongoDB MySQL Namesilo Nginx Node npm numpy Nvidia Nvidia-Docker onevps OpenCV Openpose openpyxl oss Outline parse PayPal PHP php-fpm PhpStorm PHP扩展 PIL Pillow pip PNG POST Protobuf PyCharm pyenv pymongo Python Python,人工智能,机器学习,VOC,xml Queue Redis requests RGB Sanctum save selenium SEO Shadowsock Shadowsocks ShadowsocksR simplemde Spring Boot SQLServer ssd SSH ssl SSL证书 SSR str Sublime sudo swap Swift Tensorflow TensorflowLite Terminal Terminator timestamp Ubuntu urllib UTC v2ray Valet Validation Validator VienBlog virtualenvs VPN VPS Vultr Web Windows WordPress Xcode xlsx yaml YAPI YUV zip zmq zsh 上网下载图片主从同步云主机云存储云开发云服务器人工智能代码管理优化优惠码伪原创作弊与反作弊免费ss账号免费提现切片前端加密协议博客友链双击事件后台运行后端命令国内镜像源图标图片操作图片转换域名多身份认证大小写转换姿态检测安卓模拟器安装定时任务定时执行密码密钥导出导入小程序码延迟加载异常微信微信小程序快捷方式慢查询懒加载提现搜索引擎搬瓦工搭梯子教程数据库数据重复文件上传无法登录日志日期时区时间时间戳服务器机器学习权限梯子模拟浏览器港版支付宝漏洞爬虫生活服务用户管理病毒登录目标检测科学上网系统升级索引组件组件开发编辑器自动付款自定义组件英文伪原创计划任务计算机视觉订阅通知认证语法读写分离远程仓库远程连接配置文件重定向错误异常错误提示队列阿里云香港香港手机号

亲情非友情链接

DATETIME与TIMESTAMP比较与使用

DATETIME&TIMESTAMP

猜你喜欢

评论

未登录

标签