Avete controllato il piano di esecuzione una volta che il tempo passa in su? Il piano potrebbe cambiare in base alle statistiche. Dal momento che i tuoi dati crescono rapidamente, le statistiche cambieranno e questo potrebbe innescare un piano di esecuzione diverso.
I cicli nidificati fanno bene a piccole quantità di dati, ma come potete vedere, il tempo aumenta con il volume. L'SQL Query Optimizer quindi passa probabilmente a un piano di hashing o di unione che è coerente per grandi volumi di dati.
Per confermare rapidamente questa teoria, provare a disabilitare l'aggiornamento automatico delle statistiche ed eseguire nuovamente il test. Non dovresti vedere il "bernoccolo" allora.
EDIT: Dal momento che Falcon ha confermato che le prestazioni sono cambiate a causa delle statistiche, possiamo elaborare i prossimi passi.
Immagino che tu faccia un inserto uno per uno, corretto? In tal caso, se non è possibile inserire bulk, sarà molto meglio inserirli in una tabella di lavoro heap, quindi a intervalli regolari spostare le righe in blocco nella tabella di destinazione. Questo perché per ogni riga inserita, SQL deve controllare duplicati chiave, chiavi esterne e altri controlli e ordinare e dividere le pagine tutto il tempo.Se ti puoi permettere di posticipare questi controlli per un po 'più tardi, credo che otterrai una prestazione eccellente.
Ho usato questo metodo per la registrazione delle metriche. La registrazione andrebbe in una tabella di heap normale senza indici, senza chiavi esterne, senza controlli. Ogni dieci minuti creo una nuova tabella di questo tipo, quindi con due "sp_rename" all'interno di una transazione (swift swap). Rendo disponibile l'intera tabella per l'elaborazione e la nuova tabella prende la registrazione. Allora hai il conforto di fare tutto il controllo, lo smistamento, la suddivisione solo una volta, alla rinfusa.
A parte questo, non sono sicuro di come migliorare la situazione. È certamente necessario aggiornare regolarmente le statistiche poiché questa è la chiave per una buona prestazione in generale.
Potrebbe tentare di utilizzare una singola chiave cluster di identità di colonna e un indice univoco aggiuntivo su quelle tre colonne, ma sono dubbioso che sarebbe di grande aiuto.
Potrebbe provare a riempire gli indici, se i dati inseriti non sono sequenziali. Ciò eliminerebbe l'eccessiva divisione delle pagine, mescolamento e frammentazione. Avrai bisogno di mantenere il padding regolarmente che potrebbe richiedere un tempo di pausa.
Potrebbe cercare di dargli un aggiornamento HW. Avrai bisogno di capire quale componente è il collo di bottiglia. Potrebbe essere la CPU o il disco, il mio preferito in questo caso. La memoria non è probabile se hai uno per uno inserisce. Dovrebbe essere facile quindi, se non è la CPU (la linea appesa sopra il grafico), è molto probabile che il tuo IO ti trattiene. Prova un controller migliore, un disco migliore e più veloce ...
i picchi presumibilmente saranno lo SQL lazy writer –
BTW, un indice cluster su 3 bigints è una cattiva idea. –
Perché è quello? Cosa vorresti proporre? – Falcon