É uma boa ideia indexar o campo datetime no mysql?


137

Estou trabalhando no design de um banco de dados grande. Na minha aplicação, terei muitas linhas, por exemplo, atualmente tenho uma tabela com 4 milhões de registros. A maioria das minhas consultas usa a cláusula datetime para selecionar dados. É uma boa ideia indexar campos de data e hora no banco de dados mysql?

Select field1, field2,.....,field15
from table where field 20 between now() and now + 30 days 

Estou tentando manter meu banco de dados funcionando bem e as consultas sendo executadas sem problemas

Além disso, que idéia você acha que eu deveria ter para criar um banco de dados de alta eficiência?


O que é field 20?
AlikElzin-kilaka 16/07/19

Respostas:


164

O MySQL recomenda o uso de índices por vários motivos, incluindo a eliminação de linhas entre condições: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

Isso torna sua coluna de data e hora um excelente candidato para um índice, se você a estiver usando em condições frequentes nas consultas. Se sua única condição for BETWEEN NOW() AND DATE_ADD(NOW(), INTERVAL 30 DAY)e você não tiver outro índice, o MySQL precisará fazer uma varredura completa da tabela em todas as consultas. Não tenho certeza de quantas linhas são geradas em 30 dias, mas contanto que seja menos de 1/3 do total de linhas, será mais eficiente usar um índice na coluna.

Sua pergunta sobre a criação de um banco de dados eficiente é muito ampla. Eu diria para garantir que ela esteja normalizada e que todas as colunas apropriadas sejam indexadas (ou seja, aquelas usadas nas junções e nas cláusulas where).


3
Obrigado pela explicação. Isso realmente ajuda. Tenho certeza de que terei mais filtros. Eu só quero garantir que a indexação do campo data e hora seja uma boa ideia ou não, pois podemos ter data e hora duplicadas. mas você respondeu explicou :) Obrigado
Jaylen 17/03

4
+1 para 'aqueles usados ​​em cláusulas joins e where'. Uma ótima regra geral para uma estratégia de indexação. Óbvio agora eu penso sobre isso, mas não tinha me ocorrido antes
Gaz_Edge

1
Mas se você consultar os dados com intervalo de datas , como "01-01-2017 11:20" a "03-01-2018 12:12", isso não tornará a SELECTconsulta mais rápida, apesar de eu ter indexado a date timecoluna. .. índice agiliza a consulta quando uso a equaloperação .. Estou certo?
user3595632

1
Que tal se a consulta de campos de data e hora com hora funciona como DAY (data e hora) ou HOUR (data e hora). O índice ajudará ou dificultará neste caso?
cronoklee

oi @Explosion Pills, se eu só precisar consultar a base da tabela em ano e mês, obterei um melhor desempenho se eu criar uma nova coluna com apenas ano e mês e indexá-la, em vez de criar um índice da coluna datetime diretamente ? Como que eu criar uma coluna cujo valor é como 201801.
Madeiras Chen

18

Aqui, os testes realizados pelo autor mostraram que o carimbo de data e hora unix inteiro é melhor que o DateTime. Note, ele usou o MySql. Mas acho que não importa qual mecanismo de banco de dados que você usa para comparar números inteiros seja um pouco mais rápido que comparar datas, portanto, o índice int é melhor que o índice DateTime. Tome T1 - tempo de comparar 2 datas, T2 - tempo de comparar 2 números inteiros. A pesquisa no campo indexado leva aproximadamente O (log (linhas)) tempo, porque o índice é baseado em alguma árvore balanceada - pode ser diferente para diferentes mecanismos de banco de dados, mas mesmo assim o Log (linhas) é uma estimativa comum. (se você não usar o índice baseado em máscara de bits ou em árvore r). Portanto, a diferença é (T2-T1) * Log (linhas) - pode desempenhar um papel se você executar sua consulta com frequência.


Obrigado. Eu estava pensando nisso como uma opção, mas não sabia como abordá-lo. Eu acredito que você está absolutamente certo, os números são sempre mais rápidos.
Jaylen

62
Melhor? Duvido que um timestamp unix seja melhor para todos os casos. Sim, armazenar um número inteiro geralmente é mais rápido que armazenar uma string, mas e todas as funções DateTime que o MySQL expõe? A implementação você mesmo teria um efeito negativo no desempenho ou na funcionalidade.
Greg
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.