Il conteggio di selezione semplice (id) utilizza il 100% delle DTU SQL di Azure

Questo è iniziato come this question ma ora sembra più opportunamente richiesto in quanto ho capito che si tratta di una questione correlata a DTU.Il conteggio di selezione semplice (id) utilizza il 100% delle DTU SQL di Azure

In sostanza, in esecuzione:

select count(id) from mytable

EDIT: Aggiunta di una clausola WHERE non sembra aiutare.

sta prendendo tra l'8 e il 30 minuti per eseguire (mentre la stessa query su una copia locale di SQL Server richiede circa 4 secondi ).

Di seguito è riportata una schermata della scheda MONITOR nel portale di Azure quando si esegue questa query. Nota L'ho fatto dopo aver toccato il Database per circa una settimana e il reporting di Azure che avevo usato solo l'1% dei miei DTU.

enter image description here

Un paio di cose in più:

In questo particolare test, la query ha preso 08: 27s a correre.
Mentre era in esecuzione, il grafico sopra mostrava effettivamente la linea DTU al 100% per un periodo.
Il database è configurato livello di servizio standard con livello di prestazioni S1.
Il database è di circa 3,3 GB e questa è la tabella più grande (il conto restituisce circa 2.000.000).

mi rendo conto che potrebbe essere solo la mia comprensione limitata, ma se qualcuno potesse chiarire se questo è davvero il comportamento previsto (vale a dire un conteggio semplice così tanto tempo per correre e maxing la mia DTU) che sarebbe molto apprezzato.

fonte

2014-09-27 chrisb

Le risposte nella domanda originale coprono già ciò che accade. Il conteggio "semplice" è in realtà artificioso, costoso e deve eseguire la scansione dell'intero tavolo. * Non farlo *. Se si disponesse di una clausola WHERE che utilizzava i campi indicizzati, l'ottimizzatore userebbe un'operazione di ricerca dell'indice con prestazioni decisamente migliori. Una ricerca legge l'indice B-Tree per trovare le righe corrispondenti prima di calcolare il totale (cioè molto meno IO, migliore velocità). Se utilizzi un campo con un'elevata selettività, dovrai leggere molto meno pagine indice. –

Solo FTR, il conteggio "semplice" non è ideato - è ciò che devo fare con/senza clausole diverse. – chrisb

Hai mai avuto una risposta soddisfacente perché questo sta accadendo? Vedo la stessa cosa con S2 (50 DTU) su un database da 127 GB con una tabella singola di 550 milioni di righe e il conteggio (1) richiede quasi un'ora. –

-1

select count

necessario eseguire la scansione di indice cluster, se disponibile e la sua fino ad oggi. SQL di Azure dovrebbe aggiornare automaticamente le statistiche, ma non ricostruisce automaticamente gli indici se sono completamente obsoleti.

se c'è un sacco di traffico INSERT/UPDATE/DELETE su quella tabella, suggerisco di ricostruire manualmente gli indici ogni tanto.

http://blogs.msdn.com/b/dilkushp/archive/2013/07/28/fragmentation-in-sql-azure.aspx

e così inviare per ulteriori informazioni

SQL Azure and Indexes

fonte

2014-10-07 07:57:08 b0rg

Grazie, ho ricostruito gli indici, penso di usare l'SQL nell'articolo MSDN a cui ti sei collegato. Questa tabella sembra avere un INDICE CLUSTERED che è frammentato allo 0,2%. Quindi per quanto posso dire questo non è il problema. – chrisb

@chrisb Si sta utilizzando un esempio forzato che garantisce letture costose (in termini di IO). Non è * rappresentativo di domande reali. Se hai usato anche un singolo campo indicizzato nella clausola WHERE, le prestazioni sarebbero molto più veloci –

@chrisb Penso che questo sia il punto in cui avremo bisogno di dare un'occhiata alle statistiche e ai piani di esecuzione. ecco la guida di base su come accenderli: http://www.solidq.com/tuning-sql-azure-databases-part-1/ – b0rg

Dalle statistiche di query nel previous question possiamo vedere:

300ms CPU time 
8000 physical reads

8:30 è di circa 500sec. Certamente non siamo vincolati alla CPU. La CPU da 300 ms oltre i 500 secondi non ha quasi nessun utilizzo. Otteniamo 16 letture fisiche al secondo. Questo è molto al di sotto di ciò che può offrire un disco fisico. Inoltre, la tabella non è completamente memorizzata nella cache, come evidenziato dalla presenza di IO fisico.

Direi che sei strozzato.S1 corresponds a

934 transazioni al minuto

per qualche definizione della transazione. Questo è circa 15 trans/sec. Forse stai raggiungendo il limite di un IO fisico per transazione ?! 15 e 16 sono numeri simili sospettosamente.

Verificare questa teoria aggiornando l'istanza a un fattore di scala superiore. You might find that SQL Azure Database cannot deliver the performance you want at an acceptable price.

È inoltre dovrebbe trovare che più volte la scansione la metà dei risultati della tabella in una query veloce perché il pool di buffer assegnato sembra adattarsi maggior parte del tavolo (solo che non tutti di esso).

fonte

2014-10-08 08:04:50 usr

Grazie per la tua analisi qui. Non ho avuto il tempo di verificarlo (se/quando lo avrò contrassegnato come corretto) ma penso che probabilmente sei proprio qui - Sono stato sorpreso che un semplice conteggio ... dove potrebbe prendere così tante DTU. Non ho molta esperienza con questo lato di SQL Server, quindi potrebbe essere ovvio per molti che questa è un'operazione così costosa. – chrisb

Definire "costoso". Richiede la scansione della tabella (o qualche indice di esso). Penso che abbia senso che questo produca IO in proporzione alle dimensioni del tavolo. Produce un carico CPU trascurabile. – usr

Immagino quindi di dire costoso in termini di DTU che è essenzialmente ciò che si paga con i diversi livelli di SQL di Azure. – chrisb

Ho avuto lo stesso problema. Aggiornamento delle statistiche con fullscan sul tavolo risolto:

update statistics mytable with fullscan

fonte

2017-07-12 06:47:00 Magu

Il conteggio di selezione semplice (id) utilizza il 100% delle DTU SQL di Azure

risposta

Problemi correlati