MySQL 5.5 Community Server MySQL 5.6 Community Server Percona Configuration Wizard XtraBackup 搭建主从复制 Great Sites on MySQL Percona MySQL Performance Blog Severalnines 推荐管理工具 Sequel Pro phpMyAdmin 推荐书目 MySQL Cookbook
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html 
这是一个创建于 3064 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，MySQL 中时间到底怎么存储最好，datetime、timestamp or int ? 为什么？
第 1 条附言 2017-08-08 18:29:01 +08:00
感觉这个问题没有绝对答案，需要根据应用场景，总结一下各位的答案：
-
int
优点： 存储基本类型，精度高，范围查找快
缺点： 使用 cursor 分页时很容易出问题；需要转化；
-
timestamp
优点： 方便时间函数操作
缺点： 会随时区变化
-
datetime
优点：方便时间函数操作
根据各位的建议选 datetime 或者 int 比选 timestamp 方便一些，不知道我理解的对不对。
 | 1 lol173 2017-08-08 11:42:10 +08:00 我做过的大多数项目都是用 int，如果我主导的话，我会用 timestamp |
 | 2 strict 2017-08-08 12:17:33 +08:00 你存 int，到时 sqlalchemy 怎么 filter |
 | 3 siteshen 2017-08-08 12:56:18 +08:00 epoch 用 int 精度不够，使用 cursor 分页时很容易出问题。 一直用的 timestamp with time zone (postgres)。 @strict filter 前转成 int Query.filter(user.created_at < datetime.now()) # timestamp Query.filter(user.created_at < TO_INT(datetime.now())) # int |
 | 4 syncher OP |
 | 5 moult 2017-08-08 13:09:02 +08:00 via iPhone 如果存储时间都不用 datetime，那么 MySQL 这个字段类型设计出来干嘛用？ 回归实际的话，看你需求了。脱离需求谈设计愧对扯淡。 |
 | 6 Infernalzero 2017-08-08 13:44:24 +08:00 int or bigint 数据库一般只用最基本类型 |
| 7 syncher OP @moult @Infernalzero 感谢回复，我大概找到答案了，同意 @moult 说的看需求 https://stackoverflow.com/questions/409286/should-i-use-field-datetime-or-timestamp |
 | 8 U7Q5tLAex2FI0o0g 2017-08-08 13:51:26 +08:00 一直都用 datetime 或 date |
 | 9 lshero 2017-08-08 13:55:16 +08:00 via Android 更应该考虑是否可能会面临时区转换问题 |
| 10 syncher OP @littleylv 我是想如果用 datetime 是不是不便于查找，我想在该列上建立索引，这样是不是应该用 int? |
 | 11 LYEHIZRF 2017-08-08 14:07:49 +08:00 mysql 有很多 date 相关函数可以看看 |
| 12 LYEHIZRF 2017-08-08 14:09:03 +08:00 timestamp 会随时区变化 |
 | 13 surfire91 2017-08-08 14:17:07 +08:00 偏向于 timestamp or datetime （看具体需求了），而不是 int or bigint , 因为有很多 date 函数方便使用。 |
| 14 U7Q5tLAex2FI0o0g 2017-08-08 14:18:43 +08:00 @syncher #10 一般时间字段没必要建索引吧。至于查找，无非就是时间段吧，直接 between |
 | 15 nullen 2017-08-08 14:54:15 +08:00 用 datetime |
 | 17 danielmiao 2017-08-08 15:07:40 +08:00 bigint,可以支持到 ms，剩下所有的转换都在代码完成，减少数据库运算量 |
 | 18 magicdawn 2017-08-08 15:21:00 +08:00 datetime 或者 int 都可以, timestamp 随时区变化...不好 http://magicdawn.ml/2017/05/18/mysql-timezone/ |
 | 19 solomaster 2017-08-08 16:12:34 +08:00 @magicdawn 为什么随时区变化不好？难道不是更方便用户吗？全球各地用户看到都是当地时间。 |
 | 20 loveCoding 2017-08-08 16:29:50 +08:00 datetime |
 | 21 bk201 2017-08-08 16:32:45 +08:00 @Infernalzero 你时区还要另外存吗 |
| 22 danielmiao 2017-08-08 16:35:53 +08:00 @solomaster 第一时区是数据库服务器时区或者是你应用服务器的时区，并不是访问用户的时区，实际使用中出问题的概率远大于方便。试想某一台服务器的时区设置有误。。。在复杂的分布式环境下。。。要多久才能排查到服务器时区的问题。。。。 |
 | 23 zjsxwc 2017-08-08 16:36:21 +08:00 我习惯 bigint 存时间戳 |
| 24 solomaster 2017-08-08 17:51:26 +08:00 @danielmiao 噢噢对，是根据服务器所在地的时区来的。刚才脑子抽了想到另一个问题上去了…… |
 | 25 ngloom 2017-08-08 18:45:58 +08:00 第一份工作里用的是 string 存的时间串, 跳了以后公司里用的是 datetime, 后者比前者好太多... |
| 26 Infernalzero 2017-08-08 20:09:56 +08:00  1 @bk201 都存整形了还和时区有啥关系 |
 | 28 realpg PRO bigint 大法好 |
 | 29 myzyq 2017-08-09 07:03:33 +08:00 via Android datetime 肯定比 int 有用的多，看你需要这个时间做什么，如果你只是存个时间记录下，datetime 肯定更直观，如果需要一些筛选操作,datetime 的可操作性更高！ timestamp 基本没用过！ |
Select Language