通常存储时间用datetime类型，现在很多系统也用int存储时间，它们有什么区别？个人更喜欢使用int这样对于日期计算时比较好哦，下面我们一起来看到底那种会好些。int（1）.4个字节存储，INT的长度是4个字节，存储空间上比datatime少，int索引存储空间也相对较小，排序和查询效率相对较高一点点（2）可读性极差，无法直观的看到数据，可能让你很恼火TIMESTAMP（1）4个字节储存（2）值以UTC格式保存（3）时区转化 ，存储时对当前的时区进行转换，检索时再转换回当前的时区。（4）TIMESTAMP值不能早于1970或晚于2037datetime（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-lockingkey_buffer = 128Mmax_allowed_packet = 1Mtable_cache = 512sort_buffer_size = 2Mread_buffer_size = 2Mread_rnd_buffer_size = 8Mmyisam_sort_buffer_size = 8Mthread_cache_size = 8query_cache_type = 0query_cache_size = 0thread_concurrency = 4测试DATETIME   14111 14010        14369     130000000TIMESTAMP  13888        13887        14122     90000000INT        13270        12970        13496     90000000执行mysqlmysql> 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: 0mysql> 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: 44mysql> 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: 0As 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)