2011-01-04 12 views
35

Permítanme comenzar diciendo que he visto muchas preguntas similares, pero todas se relacionan con Timestamp y DateTime tipo de campo sin indexación. Al menos eso es lo que yo entiendo.MySQL Integer frente al DateTime índice

Como todos sabemos, hay ciertas ventajas cuando se trata de DateTime. Poniendo a un lado por un minuto, y suponiendo que el motor de la mesa es InnoDB con 10+ million records, que consulta llevaría a cabo más rápido cuando los criterios se basan en:

  1. DateTime con el índice
  2. int con el índice

En otras palabras, es mejor almacenar la fecha y la hora como DateTime o UNIX timestamp en int? Tenga en cuenta que no es necesario utilizar ninguna función MySQL incorporada.

actualización

probado con MySQL 5.1.41 (64 bits) y 10 millones de discos, las pruebas iniciales mostraron diferencia de velocidad significativa a favor de int. Se usaron dos tablas, tbl_dt con DateTime y tbl_int con la columna int. Pocos resultados:

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) 

voy a publicar otra actualización con los dos campos en una tabla según lo sugerido por shantanuo.

Actualización # 2

Los resultados finales después de numerosas caídas de los servidores :) tipo int es significativamente más rápido, no importa lo que la consulta se ejecuta, la diferencia de velocidad era más o menos lo mismo que los resultados anteriores.

"Extraño" se observó que el tiempo de ejecución era más o menos el mismo cuando dos tipos de campo se almacenan en la misma tabla. Parece que MySQL es lo suficientemente inteligente como para saber cuándo los valores son los mismos cuando se almacenan tanto en DateTime como en int. No he encontrado ninguna documentación sobre el tema, por lo tanto, es solo una observación.

+0

¿Lo intentó? ¿Por qué no configurar un punto de referencia rápido y averiguarlo? – ircmaxell

+0

Trabajando en ello mientras hablamos, lleva un tiempo llenar 10 millones de registros con mi hardware :) –

+0

Asegúrate de SELECCIONAR SQL_NO_CACHE en tus pruebas – coolgeek

Respuesta

5

Mi instinto sería decir que las entradas son siempre más rápidas. Sin embargo, esto no parece ser el caso

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

Editado para añadir: Me doy cuenta de que está utilizando InnoDB, en lugar de MyISAM, pero no he encontrado nada que contradiga esto en el caso de InnoDB. Además, el mismo autor hizo una prueba de InnoDB

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

+6

Solo porque usa 'WHERE datetime> UNIX_TIMESTAMP ('1970-01-01 01:30:00') Y datetime

Cuestiones relacionadas