Query molto lenta

[marziomorandi]

Buongiorno,
ho una quesry di SQL Server su una tabella con circa 180.000 record,

Select * from MKTPart Where KeyCorso = 'AB1234566' and Data conferma <> '' order by KeyCorso

La prima volta che la eseguo dopo che sql è stato avviato impiega circa 10 minuti.
Dopo la prima volta è immediata e continua così fino al prossimo riavvio di SQL.

Grazie
Saluti

Marzio

[optime]

c'è un indice su KeyCorso ?

[liberdino]

Salve,
forse da ignorante quale sono puo' essere una baggianata, ma provo a darti uno spunto:

select * from
(Select * from MKTPart Where KeyCorso = 'AB1234566' and Data conferma <> '')
order by KeyCorso

nel senso che: prima filtra e poi ordina

[Vincent.Zeno]

il secondo esempio ha una inutile ridondanza, è meglio il primo esempio.

comunque non hai risposto a quello che ti è stato chiesto:

c'è un indice su KeyCorso ?

nel caso non ci sia crealo.
normalmente, in caso di molti record presenti, la sua assenza è causa di rallentamento.

[Joe Taras]

Buongiorno,
ho una quesry di SQL Server su una tabella con circa 180.000 record,

Select * from MKTPart Where KeyCorso = 'AB1234566' and Data conferma <> '' order by KeyCorso

La prima volta che la eseguo dopo che sql è stato avviato impiega circa 10 minuti.
Dopo la prima volta è immediata e continua così fino al prossimo riavvio di SQL.

Grazie
Saluti

Marzio

Aggiungo, agli utili consigli già forniti, di verificare il tipo di dato del campo data_conferma. Da come scrivi tu è un varchar. Se è un date o datetime potresti fare una valutazione su IS NOT NULL

[Kahm]

Salve,
forse da ignorante quale sono puo' essere una baggianata, ma provo a darti uno spunto:

select * from
(Select * from MKTPart Where KeyCorso = 'AB1234566' and Data conferma <> '')
order by KeyCorso

nel senso che: prima filtra e poi ordina

io modificherei data conferma in DataConferma (tuttoAttaccato
altrimenti al query la farei: and [Data conferma] <> ''

[Joe Taras]

Si, ma questa modifica, impatta su eventuali errori sintattici, non sulla lentezza della stessa

[Dascos]

Buongiorno,
ho una quesry di SQL Server su una tabella con circa 180.000 record,

Select * from MKTPart Where KeyCorso = 'AB1234566' and Data conferma <> '' order by KeyCorso

La prima volta che la eseguo dopo che sql è stato avviato impiega circa 10 minuti.
Dopo la prima volta è immediata e continua così fino al prossimo riavvio di SQL.

Grazie
Saluti

Marzio

Se la prima volta ci mette 10 minuti è perchè deve fare una full scan, quindi non è indicizzata...
Intanto, per leggibilità e per evitare errori, racchiuderei i campi e le tabelle nei classici apici, quindi la query diventa

SELECT * FROM `MKTPart` WHERE `KeyCorso` = 'AB1234566' AND `Data conferma` <> '' ORDER BY `KeyCorso`

In seconda battuta, modifica il nome del campo "Data conferma" e usa qualcosa tipo "Data_Conferma" (niente spazi nei nomi, ti eviti un sacco di problemi)

Ultimo....quanto è importante questa query? Nel senso...la usi spesso per ogni utente/ricerca? Immagino di sì, quindi:

L'ideale, a occhio, è creare una chiave sui due campi "KeyCorso" e "Data_Conferma" (una chiave con due campi, non una chiave per ogni campo).
Questo però ha senso SE il formato della Data_Conferma è un TimeStamp oppure un int(10) e ci salvi dentro un TimeStamp oppure la rappresentazione unixhepoc della data.
A questo punto, essendo fondamentalmente un numero, l'indice lavora molto meglio che una stringa. Fatto questo, cambi la query da <> '' a > 0
Ancora meglio sarebbe valorizzare sempre la Data_Conferma, impostando che può essere null e vale 0 come predefinito, così non dovresti avere problemi con le query di inserimento

[optime]

non metterei "0" come predefinito in una data; se è vuota, meglio lasciarla NULL

[Dascos]

non metterei "0" come predefinito in una data; se è vuota, meglio lasciarla NULL

Sì anche, dipende sempre da quanto è "complesso" adattare il codice dietro (php, asp, python, non cambia molto) per trattare NULL rispetto a 0 (zero), ma, almeno secondo la mia modesta esperienza, soprattutto dovendo usare il campo come indice, è preferibile usare un valore "congruo" rispetto al campo, quindi se è un int meglio usare "zero", se è una stringa meglio usare "" (vuoto), "0000-00-00 00:00:00" se è un DateTime, current_timestamp() se è TimeStamp ecc ecc.
Ripeto, secondo me