2016-10-14 11:42发布
像这样 1476355731 的数字
1476355731
优点:数据量大的时候如果需要以该字段作为查询条件的时候查询速度会快一点(在同等条件下+合理索引情况下);缺点:查询结果不直观,需要二次处理。不过这个几乎可以忽略,如果是在客户端用sql查询的时候,mysql自带了UNIX_TIMESTAMP 和FROM_UNIXTIME 的转换函数;如果是程序处理的话,把时间戳转换成日期对象并不是什么特别麻烦的事情。
UNIX_TIMESTAMP
FROM_UNIXTIME
但要注意的是:如果用int来存储时间戳的话,请注意int值的最大值范围。
你要说弊端,那就是你去直接看数据库的时候,不知道具体的时间。
不同地区时区不一样,如果你存个2016-10-14 9:40:32,在另外的时区就不对了。存成unix时间戳,容易转换成不同时区的时间。
有些人真是这么做的,可能是觉得日期类型计算太麻烦了,不如+30*60*60这样简单。
+30*60*60
https://segmentfault.com/q/10...
参考资料:
但我看过的几乎所有讨论数据库中怎样保存时间的文章中的观点都是“使用时间戳”。
最多设置5个标签!
付费偷看金额在0.1-10元之间
优点:数据量大的时候如果需要以该字段作为查询条件的时候查询速度会快一点(在同等条件下+合理索引情况下);
缺点:查询结果不直观,需要二次处理。不过这个几乎可以忽略,如果是在客户端用sql查询的时候,mysql自带了
UNIX_TIMESTAMP
和FROM_UNIXTIME
的转换函数;如果是程序处理的话,把时间戳转换成日期对象并不是什么特别麻烦的事情。但要注意的是:如果用int来存储时间戳的话,请注意int值的最大值范围。
你要说弊端,那就是你去直接看数据库的时候,不知道具体的时间。
不同地区时区不一样,如果你存个2016-10-14 9:40:32,在另外的时区就不对了。
存成unix时间戳,容易转换成不同时区的时间。
有些人真是这么做的,可能是觉得日期类型计算太麻烦了,不如
+30*60*60
这样简单。https://segmentfault.com/q/10...
参考资料:
但我看过的几乎所有讨论数据库中怎样保存时间的文章中的观点都是“使用时间戳”。
一周热门 更多>