› 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
这是一个创建于 3096 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，MySQL 中时间到底怎么存储最好，datetime、timestamp or int ? 为什么？
第 1 条附言 · 2017 年 8 月 8 日
感觉这个问题没有绝对答案，需要根据应用场景，总结一下各位的答案：
-
int
优点： 存储基本类型，精度高，范围查找快
缺点： 使用 cursor 分页时很容易出问题；需要转化；
-
timestamp
优点： 方便时间函数操作
缺点： 会随时区变化
-
datetime
优点：方便时间函数操作
根据各位的建议选 datetime 或者 int 比选 timestamp 方便一些，不知道我理解的对不对。
 |
1
lol173 2017 年 8 月 8 日
我做过的大多数项目都是用 int，如果我主导的话，我会用 timestamp
|
 |
2
strict 2017 年 8 月 8 日
你存 int，到时 sqlalchemy 怎么 filter
|
 |
3
siteshen 2017 年 8 月 8 日
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 |
 |
5
moult 2017 年 8 月 8 日 via iPhone
如果存储时间都不用 datetime，那么 MySQL 这个字段类型设计出来干嘛用？
回归实际的话，看你需求了。脱离需求谈设计愧对扯淡。 |
 |
6
Infernalzero 2017 年 8 月 8 日
int or bigint
数据库一般只用最基本类型 |
 |
7
syncher OP @moult @Infernalzero 感谢回复，我大概找到答案了，同意 @moult 说的看需求
https://stackoverflow.com/questions/409286/should-i-use-field-datetime-or-timestamp |
 |
8
U7Q5tLAex2FI0o0g 2017 年 8 月 8 日
一直都用 datetime 或 date
|
 |
9
lshero 2017 年 8 月 8 日 via Android
更应该考虑是否可能会面临时区转换问题
|
 |
11
LYEHIZRF 2017 年 8 月 8 日
mysql 有很多 date 相关函数可以看看
|
|
12
LYEHIZRF 2017 年 8 月 8 日
timestamp 会随时区变化
|
 |
13
surfire91 2017 年 8 月 8 日
偏向于 timestamp or datetime （看具体需求了），而不是 int or bigint , 因为有很多 date 函数方便使用。
|
|
14
U7Q5tLAex2FI0o0g 2017 年 8 月 8 日
@syncher #10 一般时间字段没必要建索引吧。至于查找，无非就是时间段吧，直接 between
|
 |
15
nullen 2017 年 8 月 8 日
用 datetime
|
 |
17
danielmiao 2017 年 8 月 8 日
bigint,可以支持到 ms，剩下所有的转换都在代码完成，减少数据库运算量
|
 |
18
magicdawn 2017 年 8 月 8 日
datetime 或者 int 都可以, timestamp 随时区变化...不好
http://magicdawn.ml/2017/05/18/mysql-timezone/ |
 |
19
solomaster 2017 年 8 月 8 日
@magicdawn 为什么随时区变化不好？难道不是更方便用户吗？全球各地用户看到都是当地时间。
|
 |
20
loveCoding 2017 年 8 月 8 日
datetime
|
 |
21
bk201 2017 年 8 月 8 日
@Infernalzero 你时区还要另外存吗
|
|
22
danielmiao 2017 年 8 月 8 日
@solomaster 第一时区是数据库服务器时区或者是你应用服务器的时区，并不是访问用户的时区，实际使用中出问题的概率远大于方便。试想某一台服务器的时区设置有误。。。在复杂的分布式环境下。。。要多久才能排查到服务器时区的问题。。。。
|
 |
23
zjsxwc 2017 年 8 月 8 日
我习惯 bigint 存时间戳
|
|
24
solomaster 2017 年 8 月 8 日
@danielmiao 噢噢对，是根据服务器所在地的时区来的。刚才脑子抽了想到另一个问题上去了……
|
 |
25
ngloom 2017 年 8 月 8 日
第一份工作里用的是 string 存的时间串,
跳了以后公司里用的是 datetime, 后者比前者好太多... |
|
26
Infernalzero 2017 年 8 月 8 日  1
@bk201 都存整形了还和时区有啥关系
|
 |
28
realpg PRO bigint 大法好
|
 |
29
myzyq 2017 年 8 月 9 日 via Android
datetime 肯定比 int 有用的多，看你需要这个时间做什么，如果你只是存个时间记录下，datetime 肯定更直观，如果需要一些筛选操作,datetime 的可操作性更高！ timestamp 基本没用过！
|
Select Language