sql >> Database teknologi >  >> RDS >> Oracle

Hvordan fortolker du en forespørgsels forklaringsplan?

Jeg gyser, når jeg ser kommentarer om, at fulde tabelscanninger er dårlige, og indeksadgang er god. Fuld tabel scanninger, indeks range scanninger, hurtige fulde indeks scanninger, nestede loops, merge join, hash joins osv. er ganske enkelt adgangsmekanismer, der skal forstås af analytikeren og kombineres med viden om databasestrukturen og formålet med en forespørgsel i for at nå frem til en meningsfuld konklusion.

En fuld scanning er simpelthen den mest effektive måde at læse en stor del af blokkene i et datasegment (en tabel eller en tabel(under)partition på), og selvom det ofte kan indikere et ydeevneproblem, er det kun i konteksten af, om det er en effektiv mekanisme til at nå målene for forespørgslen. Når vi taler som datavarehus og BI-mand, er mit nummer et advarselsflag for ydeevne en indeksbaseret adgangsmetode og en indlejret loop.

Så for mekanismen for, hvordan man læser en forklaringsplan, er Oracle-dokumentationen en god guide:http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009

Læs også Performance Tuning Guide.

Har også en google efter "kardinalitetsfeedback", en teknik, hvor en forklaringsplan kan bruges til at sammenligne vurderingerne af kardinalitet på forskellige stadier i en forespørgsel med de faktiske kardinaliteter, der opleves under udførelsen. Wolfgang Breitling er ophavsmanden til metoden, tror jeg.

Så bundlinje:forstå adgangsmekanismerne. Forstå databasen. Forstå hensigten med forespørgslen. Undgå tommelfingerregler.



  1. SQL Pivot med flere kolonner

  2. Oracle In-Memory omkostninger

  3. Database Design 101:Partitioner i MySQL

  4. Omkostningerne ved gratis PostgreSQL-reklame