MySQL Integer与DateTime索引

Dav*_*dža 41 mysql indexing innodb

首先我要说的是,我已经查看了许多类似的问题,但所有这些问题都TimestampDateTime字段类型有关而没有索引.至少这是我的理解.

众所周知,DateTime有一些优势.把它们放在一边了一分钟,并假设表的引擎是InnoDB10+ million records,它查询将更快地执行时标准基于:

  1. 带索引的DateTime
  2. 带索引的int

换句话说,最好将日期和时间存储为DateTimeUNIX时间戳int?请记住,不需要使用任何内置的MySQL函数.

更新

经过MySQL 5.1.41(64位)和1000万条记录的测试,初步测试显示出显着的速度差异int.使用两个表,tbl_dt使用DateTimetbl_int使用int列.几个结果:

SELECT SQL_NO_CACHE COUNT(*) FROM `tbl_dt`;
+----------+
| COUNT(*) |
+----------+
| 10000000 |
+----------+
1 row in set (2 min 10.27 sec)

SELECT SQL_NO_CACHE COUNT(*) FROM `tbl_int`;
+----------+
| count(*) |
+----------+
| 10000000 |
+----------+
1 row in set (25.02 sec)

SELECT SQL_NO_CACHE COUNT(*) FROM `tbl_dt` WHERE `created` BETWEEN '2009-01-30' AND '2009-12-30';
+----------+
| COUNT(*) |
+----------+
|   835663 |
+----------+
1 row in set (8.41 sec)

SELECT SQL_NO_CACHE COUNT(*) FROM `tbl_int` WHERE `created` BETWEEN 1233270000 AND 1262127600;
+----------+
| COUNT(*) |
+----------+
|   835663 |
+----------+
1 row in set (1.56 sec)
Run Code Online (Sandbox Code Playgroud)

我将根据shantanuo的建议在一个表中发布另一个包含两个字段的更新.

更新#2

众多服务器崩溃后的最终结果:) Int类型明显更快,无论运行什么查询,速度差异或多或少与上面的结果相同.

观察到"奇怪"的事情是当两个两种字段类型存储在同一个表中时,执行时间或多或少相同.似乎MySQL足够智能,可以在存储在DateTime和int中时确定值是否相同.没有找到关于这个主题的任何文件,因此只是一个观察.

小智 10

我看到在上面的答案中提到测试中,作者基本上证明了当UNIX time提前计算时,INT获胜.


coo*_*eek 6

我的直觉是说整体总是更快.但是,情况似乎并非如此

http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with-myisam/

编辑添加:我意识到你正在使用InnoDB,而不是MyISAM,但我没有发现任何与InnoDB案例相矛盾的内容.此外,同一作者进行了InnoDB测试

http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with-innodb/

  • 只是因为他在他的查询中使用`WHERE datetime> UNIX_TIMESTAMP('1970-01-01 01:30:00')和datetime <UNIX_TIMESTAMP('1970-01-01 01:35:00')`来测试INT - 它是热闹. (7认同)