mysql数据库里的日期用timestamp还是datetime好

Posted 2023-04-02

参考技术A mysql数据库里的日期用timestamp还是datetime好 （1）4个字节储存
（2）值以UTC格式保存
（3）时区转化 ，存储时对当前的时区进行转换，检索时再转换回当前的时区。
（4）TIMESTAMP值不能早于1970或晚于2037！

timestamp在数据库里实际记载的时间是国际标准时间，同一个timestamp值在不同的时区检索出来的日期时间是不一样的，因为系统会根据时区的不同进行自动时区转换，而datetime则不会进行转换时区转换，存储时是什么日期时间，检索出来的就是存入时的日期时间，它不会有变化。至于这两种日期时间类型哪种好是没有定论的，要根据实际情况和应用需求做出取舍。
请注意由于无需实施时区转换，系统处理dateime所产生的系统开销要比timestamp小。

没什么好不好的，方便省事才是王道。都用datetime 你说呢，谁在乎那点存储

类型

类型 存储需求 格式 时间范围
datetime 8个字节 yyyy-mm-dd hh-mm-ss 1000-01-01 00:00:00 到9999-12-31 23:59:59 timestamp 4个字节 yyyy-mm-dd hh-mm-ss 1970-01-01 00:00:00 到2037-12-31 23:59:59
timestamp类型会有时区变量的影响，跨时区使用时应注意

datetime 8个字节 yyyy-mm-dd hh-mm-ss 1000-01-01 00:00:00 到9999-12-31 23:59:59
timestamp 4个字节 yyyy-mm-dd hh-mm-ss 1970-01-01 00:00:00 到2037-12-31 23:59:59
timestamp类型会有时区变量的影响，跨时区使用时应注意

没什么好不好的,方便省事才是王道。都用datetime 你说呢,谁在乎那点存储 类型 类型 存储需求 格式 时间范围 datetime 8个字节

Mysql中经常用来存储日期的数据类型有2种：Date、Datetime.

1.Date数据类型：用来存储没有时间的日期。Mysql获取和显示这个类型的格式为“YYYY-MM-DD”。支持的时间范围为“1000-00-00”到“9999-12-31”。

2.Datetime类型：存储既有日期又有时间的数据。存储和显示的格式为 “YYYY-MM-DD HH:MM:SS”。支持的时间范围是“1000-00-00 00:00:00”到“9999-12-31 23:59:59”。

TIMESTAMP列用于INSERT或UPDATE操作时记录日期和时间。如果你不分配一个值，表中的第一个TIMESTAMP列自动设置为最近操作的日期和时间。也可以通过分配一个NULL值，将TIMESTAMP列设置为当前的日期和时间。

TIMESTAMP值返回后显示为'YYYY-MM-DDHH:MM:SS'格式的字符串，显示宽度固定为19个字符。如果想要获得数字值，应在TIMESTAMP列添加+0。

注释：MySQL4.1以前使用的TIMESTAMP格式在MySQL5.1中不支持；关于旧格式的信息参见MySQL4.1参考手册。

datetime
1. 占用8个字节
2. 允许为空值，可以自定义值，系统不会自动修改其值。
3. 实际格式储存（Just stores what you have stored and retrieves the same thing which you have stored.）
4. 与时区无关（It has nothing to deal with the TIMEZONE and Conversion.）
5. 不可以设定默认值，所以在不允许为空值的情况下，必须手动指定datetime字段的值才可以成功插入数据。
6. 可以在指定datetime字段的值的时候使用now()变量来自动插入系统的当前时间。
结论：datetime类型适合用来记录数据的原始的创建时间，因为无论你怎么更改记录中其他字段的值，datetime字段的值都不会改变，除非你手动更改它。

timestamp
1. 占用4个字节
2. 允许为空值，但是不可以自定义值，所以为空值时没有任何意义。
3. TIMESTAMP值不能早于1970或晚于2037。这说明一个日期，例如'1968-01-01'，虽然对于DATETIME或DATE值是有效的，但对于TIMESTAMP值却无效，如果分配给这样一个对象将被转换为0。
4.值以UTC格式保存（ it stores the number of milliseconds）
5.时区转化 ，存储时对当前的时区进行转换，检索时再转换回当前的时区。
6. 默认值为CURRENT_TIMESTAMP()，其实也就是当前的系统时间。
7. 数据库会自动修改其值，所以在插入记录时不需要指定timestamp字段的名称和timestamp字段的值，你只需要在设计表的时候添加一个timestamp字段即可，插入后该字段的值会自动变为当前系统时间。
8. 以后任何时间修改表中的记录时，对应记录的timestamp值会自动被更新为当前的系统时间。
结论：timestamp类型适合用来记录数据的最后修改时间，因为只要你更改了记录中其他字段的值，timestamp字段的值都会被自动更新。
看完这个比较你就知道用哪个好啦
我们公司一般用datatime,可控性比较强
jdbc查询Mysql数据库的日期问题
你没说错！
查出来可以保存为String类型 具体转化一下就OK了
BBSXP 用的MYSQL数据库还是MSSQL数据库
BBSXP同时支持Aess数据库和MSSQL数据库
在Config.asp文件里定义：
IsSqlDataBase=1 '定义数据库类别，0为Aess数据库，1为SQL数据库
不知道你是哪个版本，在BBSxp 2008 SP2里Config.asp文件在根目录下。内容如下：
<%
InstallIPAddress="127.0.0.1" '安装BBSXP的IP地址，针对install.asp的访问权限
TablePrefix="BBSXP_" '数据库表的前辍名（一般不用更改）
IsSqlDataBase=0 '定义数据库类别，0为Aess数据库，1为SQL数据库
If IsSqlDataBase=0 Then
'''''''''''''''''''''''''''''' Aess数据库设置 '''''''''''''''''''''''''''''''''''''''''''''''''''''''''
SqlDataBase = "database/bbsxp2008.mdb" '数据库路径
SqlProvider = "Microsoft.Jet.OLEDB.4.0" '驱动程序[ Microsoft.Jet.OLEDB.4.0 Microsoft.ACE.OLEDB.12.0 ]
SqlPassword = "" 'ACCESS数据库密码
Connstr="Provider="&SqlProvider&";Jet Oledb:Database Password="&SqlPassword&"; Data Source="&Server.MapPath(SqlDataBase)
SqlNowString="Now()"
SqlChar="'"
IsSqlVer="ACCESS"
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Else
'''''''''''''''''''''''''''''' SQL数据库设置 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
SqlLocalName = "(local)" '连接IP [ 本地用 (local) 外地用IP ]
SqlUserName = "sa" 'SQL用户名
SqlPassword = "1234" 'SQL用户密码
SqlDataBase = "bbsxp" '数据库名
SqlProvider = "SQLOLEDB" '驱动程序 [ SQLOLEDB SQLNCLI ]
ConnStr="Provider="&SqlProvider&"; User ID="&SqlUserName&"; Password="&SqlPassword&"; Initial CataLog="&SqlDataBase&"; Data Source="&SqlLocalName&";"
SqlNowString="GetDate()"
IsSqlVer="MSSQL"
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
End If
'''''''''''''''''''''''''' 以下为专业人员设置选项，普通用户请勿修改 ''''''''''''''''''''''''''
Session.CodePage="936" '936(简体中文) 950(繁体中文) 65001(Unicode)
BBSxpCharset="GB2312" 'GB2312(简体中文) Big5(繁体中文) UTF-8(Unicode)
Response.Charset=BBSxpCharset
Response.Buffer=True
%>
注：
上面bbsxp7b1版本用的是Aess数据库，因为IsSqlDataBase=0
mysql数据库可以修改表的日期格式吗
日期型的字段 存储的格式是固定的不可以修改, 需要输出时 转换成需要的格式, 如果你不想输出时转换 那么需要 设为字符型的, 存储时转换. 总之 不管先转还是后转 ,一定要转

Mysql存储日期类型用inttimestamp还是datetime?

 通常存储时间用datetime类型，现在很多系统也用int存储时间，它们有什么区别？个人更喜欢使用int这样对于日期计算时比较好哦，下面我们一起来看到底那种会好些。

int

（1）.4个字节存储，INT的长度是4个字节，存储空间上比datatime少，int索引存储空间也相对较小，排序和查询效率相对较高一点点
（2）可读性极差，无法直观的看到数据，可能让你很恼火

TIMESTAMP

（1）4个字节储存
（2）值以UTC格式保存
（3）时区转化 ，存储时对当前的时区进行转换，检索时再转换回当前的时区。
（4）TIMESTAMP值不能早于1970或晚于2037

datetime

（1）8个字节储存
（2）与时区无关

（3）以‘YYYY-MM-DD HH:MM:SS‘格式检索和显示DATETIME值。支持的范围为‘1000-01-01 00:00:00‘到‘9999-12-31 23:59:59‘


mysql也是这两年才流行，性能越来越来，具体怎么存储看个人习惯和项目需求吧
分享两篇关于int vs timestamp vs datetime性能测试的文章

Myisam:MySQL DATETIME vs TIMESTAMP vs INT 测试仪

CREATE TABLE `test_datetime` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`datetime` FIELDTYPE NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM;

机型配置

kip-locking
key_buffer = 128M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 8M
thread_cache_size = 8
query_cache_type = 0
query_cache_size = 0
thread_concurrency = 4

测试

DATETIME   14111 14010        14369     130000000
TIMESTAMP  13888        13887        14122     90000000
INT        13270        12970        13496     90000000

执行mysql

mysql> select * from test_datetime into outfile ‘/tmp/test_datetime.sql’;
Query OK, 10000000 rows affected (6.19 sec)


mysql> select * from test_timestamp into outfile ‘/tmp/test_timestamp.sql’;
Query OK, 10000000 rows affected (8.75 sec)


mysql> select * from test_int into outfile ‘/tmp/test_int.sql’;
Query OK, 10000000 rows affected (4.29 sec)


alter table test_datetime rename test_int;
alter table test_int add column datetimeint INT NOT NULL;
update test_int set datetimeint = UNIX_TIMESTAMP(datetime);
alter table test_int drop column datetime;
alter table test_int change column datetimeint datetime int not null;
select * from test_int into outfile ‘/tmp/test_int2.sql’;
drop table test_int;

So now I have exactly the same timestamps from the DATETIME test, and it will be possible to reuse the originals for TIMESTAMP tests as well.

mysql> load data infile ‘/export/home/ntavares/test_datetime.sql’ into table test_datetime;
Query OK, 10000000 rows affected (41.52 sec)
Records: 10000000 Deleted: 0 Skipped: 0 Warnings: 0


mysql> load data infile ‘/export/home/ntavares/test_datetime.sql’ into table test_timestamp;
Query OK, 10000000 rows affected, 44 warnings (48.32 sec)
Records: 10000000 Deleted: 0 Skipped: 0 Warnings: 44


mysql> load data infile ‘/export/home/ntavares/test_int2.sql’ into table test_int;
Query OK, 10000000 rows affected (37.73 sec)
Records: 10000000 Deleted: 0 Skipped: 0 Warnings: 0

As expected, since INT is simply stored as is while the others have to be recalculated. Notice how TIMESTAMP still performs worse, even though uses half of DATETIME storage size.

Let’s check the performance of full table scan:

mysql> SELECT SQL_NO_CACHE count(id) FROM test_datetime WHERE datetime > ‘1970-01-01 01:30:00′ AND datetime < ‘1970-01-01 01:35:00′;
+———–+
| count(id) |
+———–+
|    211991 |
+———–+
1 row in set (3.93 sec)


mysql> SELECT SQL_NO_CACHE count(id) FROM test_timestamp WHERE datetime > ‘1970-01-01 01:30:00′ AND datetime < ‘1970-01-01 01:35:00′;
+———–+
| count(id) |
+———–+
|   211991 |
+———–+
1 row in set (9.87 sec)


mysql> SELECT SQL_NO_CACHE count(id) FROM test_int WHERE datetime > UNIX_TIMESTAMP(’1970-01-01 01:30:00′) AND datetime < UNIX_TIMESTAMP(’1970-01-01 01:35:00′);
+———–+
| count(id) |
+———–+
|    211991 |
+———–+
1 row in set (15.12 sec)

Then again, TIMESTAMP performs worse and the recalculations seemed to impact, so the next good thing to test seemed to be without those recalculations: find the equivalents of those UNIX_TIMESTAMP() values, and use them instead:

mysql> select UNIX_TIMESTAMP(’1970-01-01 01:30:00′) AS lower, UNIX_TIMESTAMP(’1970-01-01 01:35:00′) AS bigger;
+——-+——–+
| lower | bigger |
+——-+——–+
|  1800 |   2100 |
+——-+——–+
1 row in set (0.00 sec)


mysql> SELECT SQL_NO_CACHE count(id) FROM test_int WHERE datetime > 1800 AND datetime < 2100;
+———–+
| count(id) |
+———–+
|    211991 |
+———–+
1 row in set (1.94 sec)