Scarse prestazioni della query

Abbiamo una procedura di grandi dimensioni (oltre 10.000 righe) che in genere viene eseguita in 0,5-6,0 secondi a seconda della quantità di dati con cui deve lavorare. Nell'ultimo mese circa ha iniziato a richiedere più di 30 secondi dopo aver effettuato un aggiornamento delle statistiche con FULLSCAN. Quando rallenta, uno sp_recompile "risolve" il problema, fino a quando il processo di statistiche notturne viene eseguito nuovamente.

Confrontando i piani di esecuzione lenti e veloci, l'ho ridotto a una tabella / indice specifici. Quando funziona lentamente, sta stimando che ~ 300 righe vengano restituite da un indice specifico, quando corre veloce stima 1 riga. Quando viene eseguito lentamente, utilizza uno spool di tabella dopo aver effettuato una ricerca sull'indice, quando viene eseguito rapidamente non esegue lo spool di tabella.

Usando DBSS SHOW_STATISTICS, ho rappresentato graficamente l'istogramma dell'indice in Excel. Normalmente mi aspetto che il grafico sia più "ondulato", ma invece sembra una montagna, il punto più alto è 2x-3x più alto della maggior parte degli altri valori sul grafico.

Se aggiorno le statistiche su di esso, senza FULLSCAN, sembra più normale. Se poi lo eseguo nuovamente con FULLSCAN, sembra che ho descritto sopra.

Questo sembra un problema di sniffing dei parametri, e specificamente correlato alla (apparentemente) strana distribuzione dell'indice sopra.

Il proc accetta un parametro con valori di tabella, lo sniffing dei parametri può verificarsi su un parametro con valori di tabella?

EDIT: Il proc accetta anche altri 12 parametri, alcuni dei quali sono opzionali, due dei quali sono una data di inizio e fine.

L'istogramma è strano o sto abbaiando sull'albero sbagliato?

Mi sento sicuramente a mio agio nel provare a modificare la query e / o provare a modificare la mia indicizzazione. Se questa è la soluzione che è eccezionale, a quel punto la mia domanda riguarda più l'istogramma distorto.

Vorrei menzionare che si tratta di un indice cluster IDENTITÀ PK. Abbiamo due sistemi che parlano tra loro, uno un sistema legacy, uno un nuovo sistema cresciuto in casa. Entrambi i sistemi memorizzano dati simili. Per mantenerli sincronizzati, il PK su questa tabella nel nuovo sistema viene incrementato quando le cose vengono aggiunte al vecchio sistema, anche se i dati non arrivano (viene eseguito un RESEED). Quindi potrebbero esserci delle lacune nella numerazione in questa colonna. I record vengono raramente, se mai, cancellati.

Ogni pensiero sarebbe molto apprezzato. Sono più che felice di raccogliere / includere più informazioni.

Ciò ha finito per essere correlato allo sniffing dei parametri. È successo così che alcune versioni stranamente formate di questa query venivano eseguite A DESTRA DOPO che le statistiche venivano ricostruite. Quindi il piano memorizzato nella cache non era rappresentativo della maggior parte delle chiamate. Ho usato il trucco di copiare i parametri della data in variabili locali e questo funziona perfettamente, con un impatto minimo o nullo sulle prestazioni. Questo non risponde al motivo per cui l'istogramma sembra così "spento", ma spiega i miei problemi di prestazioni.