Template designed by
Query Processor & Statistics
Davide Mauri
dmauri@solidq.com
www.davidemauri.it
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 DICHIARATIVO
4° 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
SQL
Dati
(In Fretta e
Corretti)
Magi
c
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 0
end) / 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_nations
group 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 Logici
Es:JOIN
Operatori Fisici
Es:LOOP JOIN, MERGE JOIN, HASH JOIN
Query Optimization – Operatori
Query Optimization – Regole di riscrittura
Execution Plans
Ad ogni step del piano di esecuzione viene assegnato un costo
stimato
La somma totale è il costo totale del piano
Viene preso il piano con il costo minore
Per query complesse non vengono valutati tutti i piani
Tecniche 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 base
della 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 dati
Totale
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 colonna
Solo 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
demo
Data 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
statistico
L’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
dmauri@solidq.com
Grazie

Query Processor & Statistics: A Performance Primer

  • 1.
    Template designed by QueryProcessor & Statistics Davide Mauri dmauri@solidq.com www.davidemauri.it
  • 2.
  • 3.
    Works with SQLServer 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
  • 4.
    Query Processor Execution Plans DataDistribution Statistics Conclusioni agenda
  • 5.
    SQL è unlinguaggio DICHIARATIVO 4° 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
  • 6.
  • 7.
    Per ogni queryinviata, il ciclo di vita è: Query Processor Parse Bind Optimize Execute Qui viene definito il percorso di risoluzione della query, o “Execution Plan”
  • 8.
    Optimizer: Percorsi • Comearrivare 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
  • 9.
    Query Optimization eComplessità Select o_year, sum(case when nation = 'BRAZIL' then volume else 0 end) / 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_nations group by o_year order by o_year Circa 22 Milioni di piani di esecuzioni possibili! Query del Benchmark TPC-H
  • 10.
    Enumerare piani logicamenteequivalenti 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
  • 11.
    Operatori Logici Es:JOIN Operatori Fisici Es:LOOPJOIN, MERGE JOIN, HASH JOIN Query Optimization – Operatori
  • 12.
    Query Optimization –Regole di riscrittura
  • 13.
  • 14.
    Ad ogni stepdel piano di esecuzione viene assegnato un costo stimato La somma totale è il costo totale del piano Viene preso il piano con il costo minore Per query complesse non vengono valutati tutti i piani Tecniche 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
  • 15.
    Estimated vs Actual Ovviamente,è fondamentale che la stima sia realistica Il percorso è stimato sulla base della quantità di dati sui cui si deve operare
  • 16.
    Estimated vs Actual Dall’executionplan è possibile avere informazioni su stima e valori attuali
  • 17.
    E’ necessario avereun’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
  • 18.
    Numero di righe Numerodi righe campionate Densità dei dati Totale Per prefisso Data ed Ora di campionamento Lunghezza media della chiave Numero di step (fino a 200) Data Distribution Statistics
  • 19.
    Creazione Manuale Statistiche createautomaticamente sulle colonne indicizzate Statistiche create automaticamente da SQL Server anche per le colonne non indicizzate Data Distribution Statistics
  • 20.
    Memorizzano informazioni sulladistribuzione dei dati all’interno della colonna Solo per la 1° colonna Limitati a 200 steps Histograms
  • 21.
    Da SQL Server2005 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
  • 22.
    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
  • 23.
  • 24.
    Ogni cosa cheva 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 statistico L’utilizzo di una tabella temporanea di «appoggio» può essere di grande aiuto Query Analysis & Optimization
  • 25.
    Sapere leggere edanalizzare Piani di Esecuzione Statistiche E’ fondamentale per capire e quindi ottimizare una query Conclusioni
  • 26.
    Grazie a tuttiper la partecipazione Riceverete il link per il download a slide e demo via email nei prossimi giorni Per contattarmi dmauri@solidq.com Grazie

Editor's Notes

  • #9 Usare la mappa per arrivare da Milano a Roma.