È una buona idea indicizzare il campo datetime in mysql?


137

Sto lavorando alla progettazione di un database di grandi dimensioni. Nella mia applicazione avrò molte righe, ad esempio attualmente ho una tabella con 4 milioni di record. La maggior parte delle mie query utilizza la clausola datetime per selezionare i dati. È una buona idea indicizzare i campi datetime nel database mysql?

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

Sto cercando di mantenere il mio database funzionante e le query vengono eseguite senza problemi

Inoltre, quale idea pensi che dovrei creare un database ad alta efficienza?


Cosa field 20?
AlikElzin-Kilaka,

Risposte:


164

MySQL consiglia di utilizzare gli indici per una serie di motivi, tra cui l'eliminazione delle righe tra le condizioni: http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

Ciò rende la colonna del tuo datetime un candidato eccellente per un indice se lo utilizzerai spesso in condizioni nelle query. Se la tua unica condizione è BETWEEN NOW() AND DATE_ADD(NOW(), INTERVAL 30 DAY)e non hai altri indici nella condizione, MySQL dovrà eseguire una scansione completa della tabella su ogni query. Non sono sicuro di quante righe vengano generate in 30 giorni, ma fintanto che è inferiore a circa 1/3 delle righe totali sarà più efficiente utilizzare un indice sulla colonna.

La tua domanda sulla creazione di un database efficiente è molto ampia. Direi solo per assicurarmi che sia normalizzato e che tutte le colonne appropriate siano indicizzate (cioè quelle usate nei join e nelle clausole where).


3
Grazie per la spiegazione. Questo aiuta davvero. Sono sicuro che avrò più filtri. Voglio solo assicurarmi che l'indicizzazione del campo datetime sia una buona idea o meno, dato che potremmo avere un duplicato della data e dell'ora. ma tu rispondi lo spieghi :) Grazie
Jaylen

4
+1 per "quelli usati nei join e dove clausole". Un'ottima regola empirica per una strategia di indicizzazione. Ovvio ora ci penso, ma non mi era mai venuto in mente prima
Gaz_Edge

1
Ma se esegui una query sui dati con un intervallo di date , ad esempio un intervallo di dati compreso tra "01-01-2017 11:20" e "03/01/2018 12:12", la SELECTquery non sarà più veloce anche se ho indicizzato la date timecolonna. .. L'indice rende la query veloce quando utilizzo l' equaloperazione .. Ho ragione?
user3595632

1
Che ne dite se l'interrogazione dei campi datetime con l'ora funzioni come DAY (datetime) o HOUR (datetime). L'indice aiuterà o ostacolerà in questo caso?
cronoklee,

ciao @Explosion Pills, se ho solo bisogno di interrogare la base della tabella per anno e mese, otterrò una prestazione migliore se ho creato una nuova colonna con solo anno e mese, quindi indicizzalo, invece di creare direttamente un indice della colonna datetime ? Come quello che creo una colonna il cui valore è come il 201801.
Woods Chen

18

Qui i test eseguiti dall'autore hanno mostrato che il timestamp unix intero è migliore di DateTime. Nota, ha usato MySql. Ma mi sento indifferentemente da quale motore DB usi confrontando numeri interi è leggermente più veloce rispetto al confronto delle date, quindi l'indice int è migliore dell'indice DateTime. Prendi T1 - tempo di confrontare 2 date, T2 - tempo di confrontare 2 numeri interi. La ricerca nel campo indicizzato richiede circa O (log (righe)) di tempo perché l'indice si basa su un albero bilanciato: potrebbe essere diverso per i diversi motori DB, ma comunque Log (righe) è una stima comune. (se non si utilizza la maschera di bit o l'indice basato su r-tree). Quindi la differenza è (T2-T1) * Registro (righe): può svolgere un ruolo se si esegue spesso la query.


Grazie. Ci stavo pensando come un'opzione, ma non sapevo come affrontarlo. Credo che tu abbia assolutamente ragione gli interi sono sempre più veloci.
Jaylen,

62
Meglio? Dubito che un timestamp unix sia migliore per tutti i casi. Sì, la memorizzazione di un numero intero è generalmente più veloce della memorizzazione di una stringa, ma per quanto riguarda tutte le funzioni DateTime che MySQL espone? L'implementazione da soli avrebbe un effetto negativo sulle prestazioni o sulla funzionalità.
Greg,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.