› 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
这是一个创建于 2663 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，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
littleylv 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 函数方便使用。
|
 |
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 2017-08-09 01:24:25 +08:00
bigint 大法好
|
 |
29
myzyq 2017-08-09 07:03:33 +08:00 via Android
datetime 肯定比 int 有用的多，看你需要这个时间做什么，如果你只是存个时间记录下，datetime 肯定更直观，如果需要一些筛选操作,datetime 的可操作性更高！ timestamp 基本没用过！
|
Select Language