Mi sta capitando spesso in questi giorni di paciugare con SQL per arrivare alla soluzione di alcuni problemi di performance (partendo dal presupposto che prima di tutto ci sarebbe da rifattorare _tutto_ l'applicativo, ma soprassediamo :P), e mi sono scontrato con alcuni problemi che già ha illustrato Igor in questo post.
Una cosa però che non ha evidenziato è l'importanza, che si scopre analizzando bene l'execution plan, di aggiornare le statistiche delle tabelle: per creare l'execution plan, sql server si basa sulle statistiche per decidere i vari piani e scegliere il migliore. Quindi, può succedere che su queste basi SQL server prenda delle decisioni che sembrano strano ma in realtà non lo sono, per esempio può decidere di fare un tablescan invece di utilizzare gli indici su una tabella se questa tabella ha pochi record.
Può anche succedere (come è successo al sottoscritto) che l'amministratore disabilit l'autoupdate delle statistiche, ma poi non amministri effettivamente il DB. Risultato: una tabella da 20.000 record veniva processata con un tablescan invece di usare gli indici. Questo portava a 12 secondi di query sul nostro ambiente di sviluppo interno, ed a 4 minuti e mezzo sul loro ambiente di collaudo... non male come collo di bottiglia eh? :)
Alcuni link per approfondire:
Spiegazione di come funziona l'autostat (msdn)
Tip per migliorare l'uso delle statistiche (sqlperformance)