Hur använder man Explain Plan för att optimera frågor?

Jag antar också att du använder Oracle. Och jag rekommenderar också att du kollar in förklara planens webbsida, till att börja med. Det finns mycket med optimering, men det går att lära sig.

Några tips följer:

För det första, när någon ger dig i uppdrag att optimera, letar de nästan alltid efter acceptabel prestanda snarare än ultimat prestanda. Om du kan minska en frågas körtid från 3 minuter ner till 3 sekunder, svettas inte med att minska den till 2 sekunder förrän du blir ombedd att göra det.

För det andra, gör en snabb kontroll för att se till att frågorna du optimerar är logiskt korrekta. Det låter absurt, men jag kan inte berätta hur många gånger jag har blivit tillfrågad om råd om en långsam fråga, bara för att få reda på att det ibland gav fel svar! Och som det visar sig, visade sig felsökning av frågan ofta också påskynda den.

Leta särskilt efter frasen "Cartesian Join" i förklaringsplanen. Om du ser det där är chansen oerhört god att du har hittat en oavsiktlig kartesisk join. Det vanliga mönstret för en oavsiktlig kartesisk koppling är att FROM-satsen listar tabeller separerade med kommatecken, och kopplingsvillkoren finns i WHERE-satsen. Förutom att ett av anslutningsvillkoren saknas, så att Oracle inte har något annat val än att utföra en kartesisk anslutning. Med stora bord är detta en prestandakatastrof.

Det är möjligt att se en Cartesian Join i förklaraplanen där frågan är logiskt korrekt, men jag associerar detta med äldre versioner av Oracle.

Leta också efter det oanvända sammansatta indexet. Om den första kolumnen i ett sammansatt index inte används i frågan, kan Oracle använda indexet ineffektivt eller inte alls. Låt mig ge ett exempel:

Frågan var:

select * from customers    
where
     State = @State
     and ZipCode = @ZipCode

(DBMS var inte Oracle, så syntaxen var annorlunda, och jag har glömt den ursprungliga syntaxen).

En snabb titt på indexen avslöjade ett index över kunder med kolumnerna (Land, Stat, Postnummer) i den ordningen. Jag ändrade frågan till att läsa

  select * from customers
   where Country = @Country
      and State = @State
      and ZipCode = @ZipCode

och nu gick den på cirka 6 sekunder istället för cirka 6 minuter, eftersom optimeraren kunde använda indexet med fördel. Jag frågade applikationsprogrammerarna varför de hade utelämnat landet från kriterierna, och detta var deras svar:de visste att alla adresser hade ett land lika med 'USA' så de tänkte att de kunde påskynda frågan genom att utelämna det kriteriet!

Tyvärr är att optimera databashämtning inte riktigt detsamma som att raka mikrosekunder från beräkningstiden. Det handlar om att förstå databasens design, särskilt index, och åtminstone en översikt över hur optimeraren gör sitt jobb.

Du får generellt sett bättre resultat av optimeraren när du lär dig att samarbeta med den istället för att försöka överlista den.

Lycka till när du kommer igång med optimeringen!