Velocità query con timestamp

[GianfrancoPa]

Buongiorno, da anni utilizzo un database con MySql dove inserisco i dati di stazioni meteorologiche.
Sin dall'inizio ho previsto campi tinytint(1) per la conservazione separata delle variabili anno, mese, giorno, ora, minuto, settate tutte come indice.

Dopo anni di studio dei database ho scoperto l'uso della variabile timestamp e sto provando a convertire tutte le query per utilizzare tale variabile al fine di semplificare il codice (soprattutto nelle query di ricerca) e anche di velocizzarlo: ci sono anni in cui il database raggiunge milioni di record e le ricerche sono davvero lente, talvolta davvero estenuanti.

Per tale ragione nella tabella ho aggiunto la variabile timestamp con valore predefinito currdate(). Anch'essa settata come indice.

Ho fatto un primo test:

SELECT AVG(temp), AVG(ur), AVG(wind), AVG(pressione) 
FROM database_stazioni
WHERE temp <> -17.8 AND temp <> -30 AND  temp <> 0  AND  id_stazione=7
AND Data_anno = 18 AND Data_mese = 1 AND Data_giorno = 3 AND tipo_dato='1'

0.0018 sec

SELECT AVG(temp), AVG(ur), AVG(wind), AVG(pressione) 
FROM database_stazioni
WHERE temp <> -17.8 AND temp <> -30 AND  temp <> 0  AND  id_stazione=7
AND timestamp >= CURDATE()

0.0122 sec

Le due variabili restituiscono il medesimo risultato, ma come mai la query che usa la ricerca mediante timestamp è 10 volte più lenta?

Dovendo velocizzare le query, timestamp non mi aiuta?

Grazie mille!!

[optime]

perché nella seconda manca ".. AND tipo_dato='1'" ?

[GianfrancoPa]

perché nella seconda manca ".. AND tipo_dato='1'" ?

stupida dimenticanza, ho eseguito nuovamente le query e le tempistiche non cambiano.

[optime]

ok. Credo che nelle query semplici niente possa battere le ricerche sugli interi. Le date sono ottime per le ricerche di intervalli, per calcolare il tempo intercorso tra due date, raggruppamenti temporali ecc.

Parli di ricerche "estenuanti": dato che il termine è soggettivo, potresti quantificare? Eventualmente posta una query "estenuante", che ci si butta un occhio

[badaze]

@gianfrancopa

Puoi semplificare le query facendo come segue : where (data_anno * 10000 + data_mese * 100 + data_giorno) >= 180103

[optime]

@gianfrancopa

Puoi semplificare le query facendo come segue : where (data_anno * 10000 + data_mese * 100 + data_giorno) >= 180103

forse la semplifica, ma non credo che la velocizzi. Potrebbe salvarla come SP, parametrizzarla e lasciarla eseguire al motore del db -- ammesso che MySql sia efficiente sulle SP

[marino51]

credo ci sia un'importante differenza tra le 2 query nel post iniziale,

la prima
Data_anno = 18 AND Data_mese = 1 AND Data_giorno = 3
avendo uguaglianza, utilizza gli indici

la seconda timestamp >= CURDATE()
avendo un maggiore-uguale legge in sequenza ...

magari mi sbaglio

[badaze]

Ieri era il 3 gennaio. Quindi curdate() era uguale a quella data.

[marino51]

Ieri era il 3 gennaio. Quindi curdate() era uguale a quella data.

non ho capito cosa vuoi dire,

capisco solo che maggiore-uguale impedisce l'uso di indici obbligando ad una lettura sequenziale indipendentemente dal valore da cercare impiegando quindi più tempo

la comparazione andrebbe fatta con la sola uguaglianza
AND timestamp = CURDATE()

[optime]

da considerare inoltre che timestamp() aggiunge ore:minuti:secondi e quindi quando la si confronta con CURDATE() c'è da considerare anche l'overhead della conversione. Ripeto, sulla query secca niente batte il confronto tra interi.