query processor & statistics: a performance primer
DESCRIPTION
Le performance di un database sono strettamente legate al funzionamento del suo componente più "intelligente", il query processor, ai dati presenti nel database stesso, alle query che vengono scritte e - importantissime - alle stime di distribuzione dei dati che ogni RDBMS si mantiene per poter fare al meglio il proprio lavoro. In questa sessione vederemo come tutte queste cose concorrono a produrre performance ottimali - o meno - in SQL ServerTRANSCRIPT
brought to you by
Works with SQL Server from 6.5, on BI from 2003
Specialized in Data Solution Architecture, Database Design, Performance Tuning, BI
Microsoft SQL Server MVP
President of UGISS (Italian SQL Server UG)
Mentor @ SolidQ
Regular Speaker @ SQL Server events
Consulting & Training
Davide Mauri
Query Processor
Execution Plans
Data Distribution Statistics
Conclusioni
agenda
SQL è un linguaggio DICHIARATIVO4° Generation Programming Language (4GL)
La query descrive il risultato che si vuole (ossia il «cosa»), senza indicare gli step per ottenerlo (ossia il «come»)
E’ quindi necessario un engine che si preoccupi del «come»
Query Processor Overview
Query Processor Overview
Richiesta
SQLDati
(In Fretta eCorretti)
Magic
Per ogni query inviata, il ciclo di vita è:
Query Processor
Parse Bind Optimize Execute
Qui viene definito il percorso di risoluzione della query, o “Execution Plan”
Optimizer: Percorsi
• Come arrivare da «A» a «B»?
• Valuta i possibili percorsi• E il traffico?• E se usassi un altro
mezzo?
• Da un peso a tutti i percorsi• Prende quello meno costoso
Query Optimization e Complessità
Select o_year, sum(case when nation = 'BRAZIL' then volume else 0end) / sum(volume)from( select YEAR(O_ORDERDATE) as o_year, L_EXTENDEDPRICE * (1 - L_DISCOUNT) as volume, n2.N_NAME as nation from PART, SUPPLIER, LINEITEM, ORDERS, CUSTOMER, NATION n1, NATION n2, REGION where P_PARTKEY = L_PARTKEY and S_SUPPKEY = L_SUPPKEY and L_ORDERKEY = O_ORDERKEY and O_CUSTKEY = C_CUSTKEY and C_NATIONKEY = n1.N_NATIONKEY and n1.N_REGIONKEY = R_REGIONKEY and R_NAME = 'AMERICA‘ and S_NATIONKEY = n2.N_NATIONKEY and O_ORDERDATE between '1995-01-01' and '1996-12-31' and P_TYPE = 'ECONOMY ANODIZED STEEL' and S_ACCTBAL <= constant-1 and L_EXTENDEDPRICE <= constant-2) as all_nationsgroup by o_year order by o_year
Circa 22 Milioni di piani di esecuzioni
possibili!
Query del Benchmark TPC-H
Enumerare piani logicamente equivalenti applicando regole di equivalenza
Per ciascun piano cosi generato equivalenti, enumerare tutti i piani fisici possibili
Stimare il costo di ciascuno dei piani alternativi cosi ottenuti
Eseguire il piano con il più basso costo stimato complessivo
Query Optimization – Main Steps
Operatori LogiciEs:JOIN
Operatori FisiciEs:LOOP JOIN, MERGE JOIN, HASH JOIN
Query Optimization – Operatori
Applicano trasformazioni alla query al fine di poterla riscrivere e quindi semplificareEs: Inner Join è commutativa :
Es: IN, EXISTS, INNER JOIN possono essere riscritte allo stesso modo
397 in SQL Server 2012sys.dm_exec_query_transformation_stats
Query Optimization – Regole di riscrittura
Execution Plans
Ad ogni step del piano di esecuzione viene assegnato un costo stimatoLa somma totale è il costo totale del piano
Viene preso il piano con il costo minore
Per query complesse non vengono valutati tutti i pianiTecniche di «potatura» vengono usate per evitare di percorrere ramificazioni ipoteticamente non efficienti.
Come può sapere il reale costo di ogni piano?Non può!
Necessità di stime per capire cosa ha senso fare
Cost Based Optimization
Estimated vs Actual
Ovviamente, è fondamentale che la stima sia realistica
Il percorso è stimato sulla basedella quantità di dati sui cui si deve operare
Estimated vs Actual
Dall’execution plan è possibile avere informazioni su stima e valori attuali
E’ necessario avere un’idea stimata dei dati con cui si andrà ad operare
Tanto più è verosimile la stima, tanto più i piani di esecuzioni saranno ottimali
Punti delicati
Dati distribuiti in modo non omogeneo
Dipendenze e Correlazioni
Data Distribution Statistics
Numero di righe
Numero di righe campionate
Densità dei datiTotale
Per prefisso
Data ed Ora di campionamento
Lunghezza media della chiave
Numero di step (fino a 200)
Data Distribution Statistics
Creazione Manuale
Statistiche create automaticamente sulle colonne indicizzate
Statistiche create automaticamente da SQL Server anche per le colonne non indicizzate
Data Distribution Statistics
Memorizzano informazioni sulla distribuzione dei dati all’interno della colonnaSolo per la 1° colonna
Limitati a 200 steps
Histograms
Da SQL Server 2005
SYS.STATS, SYS.STATS_COLUMNS, STAT_DATE
DBCC SHOW_STATISTICS
Da SQL Server 2008 SP2 e SQL Server 2012 SP1
SYS.DM_DB_STATS_PROPERTIES
Visualizzazione ed Analisi
Show Statistics
HEADER
DENSITY VECTOR
HISTOGRAM
123 «Alexander»28 Rows tra «Adams» e «Alexander» (limiti esclusi)- 15 Valori Distinti - 1,86 Righe per ogni valore
demoData Distribution Statistics At Work
Ogni cosa che va a deteriorare la qualità delle stime è da evitare
Evitare di applicare funzioni sulle colonne nei predicati di ricerca quando possibile
Attenzione a catene di join lunghe perché amplificano l’errore statisticoL’utilizzo di una tabella temporanea di «appoggio» può essere di grande aiuto
Query Analysis & Optimization
Sapere leggere ed analizzare
Piani di Esecuzione
Statistiche
E’ fondamentale per capire e quindi ottimizare una query
Conclusioni
Grazie a tutti per la partecipazione
Riceverete il link per il download a slide e demo via email nei prossimi giorni
Per contattarmi
Grazie