Introduktion til SQL Tuning
- Sql-sætning er skrevet for at hente /hent data fra databasen. Vi vil have vores sql-sætning til at køre hurtigt (sql-tuning) og levere resultaterne på sekunder.
- En dårligt designet sql kan bremse hele databaseoperationen og bringe hele operationen til at stoppe. Det er meget sværere at skrive effektiv SQL end det er at skrive funktionelt korrekt SQL. sql-ydeevnejustering kan forbedre et systems sundhed og ydeevne markant.
- Nøglen til at justere SQL er at minimere de data, den får adgang til for at give resultatet. Vi kan minimere de data, den får adgang til for at levere resultatet gennem optimal søgesti.
Et simpelt eksempel ville være
select * from dept where emp=10
- Nu skal denne forespørgsel søge i hele tabelafdelingen for at finde ud af data, hvor emp=10. Så den skal have adgang til hele tabellen
- Nu, hvis vi opretter kolonnen indeks til emp, så kan den bare få adgang til indekset og få resultatet. Så her får den adgang til færre data
12 trin til at udføre SQL-tuning i Oracle
Her er de generelle tips til justering af sql-ydelse
(1) Først skal du have alle de nødvendige værktøjer til sql tuning. Du skal have god information om sporing, formatering af sporingen, forklare planen, læse forklaringsplanen i Oracle.
Godt kendskab til de forskellige joinmetoder, der er tilgængelige i Oracle og hvordan man bruger dem effektivt
(2) Læs færre data og vær I/O-effektiv.
Jo flere data du læser for SQL-sætningen, jo flere låse skal den hente, og det sænker ydeevnen. så det må altid lave færre logiske læsninger
Skriv fornuftig sql-sætning, hvor de rigtige filtre . Tjek antallet af rækker i forskellige involverede tabeller og find ud af den bedste metode til at oprette sql-sætningen
(2) Brug gode Oracle-indekser
B-Tree-indekser og Bitmap-indekser kan bruges til at øge ydelsen af forespørgslerne, hvis de returnerede data er mindre end 10 %. Men vi skal være forsigtige, mens vi opretter indekset, da det også skal vedligeholdes for indsættelse, opdatering og sletning. Så oprettelse af et indeks skaber overhead over mange ting. Så vi skal omhyggeligt undersøge effekten af at oprette indekset.
(3) Undgå sql, som deaktiverer brugen af indeks
SQL, der deaktiverer indekser
(a)Funktioner ( to_char(), to_date() osv. )
Ret :flyt funktionen til siden "konstant/bind variabel"
(b) Type Casting
I SQL
hvor emp_no =10 (emp_no er en varchar2)
I PL/SQL
hvor emp_no =v_emp_num (v_emp_num er et tal)
Modifiers
og id + 0 =111
og dato + 1 =sysdate (forsøgsdato =sysdate – 1)
Ret :Skift det for at undgå det
(4) Brug altid bind variabel i applikationen. Hvis du ikke bruger bind-variablen i oracle, vil sql'en blive parset hver gang og vil påvirke databasens ydeevne. Hvis den indeholder bind-variablen, vil sql blive cachelagret, og yderligere udførelse vil ikke kræve parsing, og systemets overordnede ydeevne forbedres således.
(5) UNION vs. OR. Brug UNION til forespørgsler med to klare udførelsesstier; hver returnerer et ret lille antal rækker. Brug ikke union til forespørgsler, der sandsynligvis vil returnere et stort antal rækker, da alle rækker skal sorteres, og de fleste af dem vil blive kasseret. OR har en tendens til at deaktivere indekset
(6) Brug den nøjagtige optimeringsstatistik på bordet for at få den optimale plan.
(7) Hvis du bruger funktion på udtryk på betingelsen, skal du kontrollere, om der er et funktionsbaseret indeks på den kolonne. Hvis det ikke er til stede, vil indekset ikke blive brugt
(8) Brug eksisterer vs. i og ikke eksisterer vs. ikke i for korrelerede underforespørgsler
(9) Undgå dårlig kodningspraksis
Nogle tips
(a) Undgå Cartesian join . Sørg for, at alle de tabeller, der kræves i forespørgslerne, er nødvendige og er forbundet med hinanden
(b) Brug Decode for at undgå flere ture til databasen
(c) Forsøg at undgå outer join
(d ) Nogle gange gør det at dekomponere logikken i små dele arbejdet hurtigere
(10) Hvis du prøver at bruge den komplekse visning, skal du kontrollere, om basistabellerne kan bruges i stedet, da visningen har en tendens til at gøre ydeevnen dårlig
(11) Brug UNION ALL vs UNION, hvis du ved, at hentede data ikke vil have duplikerede rækker
( 12) Brug tip til at optimere udførelsesplanen. Nogle gange kan tip bruges til at ændre eksekveringsplanen for forespørgslen for at tage den mest optimale vej.
Nogle gange skaber binde-kigger en dårlig plan, så i så fald sætter det nødvendige tip til at rette planen, og hjælper med at få god ydeevne hver gang
De mest almindelige tip er
/*+ LEADING (tabel alias) */ angiver tabel, som skal starte joinforbindelse
/*+ FIRST_ROWS */ meget god til online skærme – favoriserer NEDEDE LOOPSER
/*+ INDEX ( tabelalias.indeksnavn) */ angiver det indeks, du vil bruge. Bemærk:hvis indeks bliver slettet og genskabt og navneændringer, er hint ikke længere gyldigt.
/*+ USE_NL (tabel alias1 tabel alias 2)*/ anmoder optimizer om at bruge Nested Loop Join til de to specificerede tabeller
Undgå unødvendige optimeringstip og brug dem med omhu
Dette er nogle af tipsene til at undgå problemer og lave sql-tuning. Sql-tuning er et stort hav, og du kan lære ting ved kun at øve dig. Held og lykke!!
Læser også
https://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_1016.htm