Introduktion till SQL Tuning
- Sql-satsen är skriven för att hämta /hämta data från databasen. Vi vill att vår sql-sats ska köras snabbt (sql-inställning) och ge resultaten på sekunder.
- En dåligt utformad sql kan sakta ner hela databasoperationen och få hela operationen att stanna. Det är mycket svårare att skriva effektiv SQL än att skriva funktionellt korrekt SQL. sql-prestandajustering kan förbättra systemets hälsa och prestanda avsevärt.
- Nyckeln till att ställa in SQL är att minimera den data den kommer åt för att ge resultatet. Vi kan minimera den data den får åtkomst till för att tillhandahålla resultatet genom optimal sökväg.
Ett enkelt exempel skulle vara
select * from dept where emp=10
- Nu måste den här frågan söka i hela tabellavdelningen för att ta reda på data där emp=10. Så den måste komma åt hela tabellen
- Om vi nu skapar kolumnen index to emp kan den bara komma åt indexet och få resultatet. Så här får den tillgång till mindre data
12 steg för att utföra SQL-inställning i Oracle
Här de allmänna tipsen för justering av SQL-prestanda
(1) Först måste du ha alla nödvändiga verktyg för sql-tuning. Du måste ha bra information om spårning, formatering av spåret, förklara planen, läsa förklaringsplanen i Oracle.
God kunskap om de olika sammanfogningsmetoderna som finns tillgängliga i Oracle och hur man använder dem effektivt
(2) Läs mindre data och var I/O-effektiv.
Ju mer data du läser för sql-satsen, desto fler spärrar behöver den förvärva och det saktar ner prestandan. så det måste alltid göra färre logiska läsningar
Skriv ett vettigt SQL-uttalande där korrekta filter . Kontrollera antalet rader i olika tabeller och ta reda på den bästa metoden för att skapa SQL-satsen
(2) Använd bra Oracle-index
B-Tree-index och Bitmap-index kan användas för att öka prestandan för frågorna om den returnerade datan är mindre än 10 %. Men vi måste vara försiktiga när vi skapar indexet eftersom det också måste underhållas för att infoga, uppdatera och ta bort. Så skapa ett index skapa overhead över många saker. Så vi måste noggrant undersöka effekten av att skapa indexet.
(3) Undvik sql som inaktiverar användningen av index
SQL som inaktiverar index
(a)Funktioner ( to_char(), to_date(), etc. )
Fix:flytta funktionen till sidan "konstant/bindningsvariabel"
(b) Typ Casting
I SQL
där emp_no =10 (emp_no är en varchar2)
I PL/SQL
där emp_no =v_emp_num (v_emp_num är ett nummer)
Modifierare
och id + 0 =111
och datum + 1 =sysdatum (försöksdatum =sysdatum – 1)
Åtgärda:Ändra det för att undvika det
(4) Använd alltid bindningsvariabel i applikationen. Om du inte använder bindvariabeln i Oracle kommer sql att tolkas varje gång och kommer att påverka databasprestandan. Om den innehåller bindningsvariabeln, skulle sql cachelagras och ytterligare exekvering kommer inte att kräva analys och därmed förbättras systemets övergripande prestanda.
(5) UNION vs OR. Använd UNION för frågor med två tydliga körningsvägar; var och en returnerar ett ganska litet antal rader. Använd inte union för frågor som sannolikt kommer att returnera ett stort antal rader eftersom alla rader måste sorteras och de flesta av dem kommer att kasseras. OR tenderar att inaktivera indexet
(6) Använd den korrekta optimerarstatistiken på bordet för att få den optimala planen.
(7) Om du använder funktion på uttryck på villkoret, kontrollera om det finns ett funktionsbaserat index på den kolumnen. Om det inte finns kommer indexet inte att användas
(8) Användning existerar vs in och Non exists vs not in för korrelerade underfrågor
(9) Undvik dåliga kodningsmetoder
Några tips
(a) Undvik kartesisk gå med . Se till att alla tabeller som krävs i frågorna behövs och är länkade till varandra
(b) Använd Decode för att undvika flera resor till databasen
(c) Försök att undvika yttre sammanfogning
(d ) Att ibland bryta ner logiken i små delar gör arbetet snabbare
(10) Om du försöker använda den komplexa vyn, kontrollera om bastabellerna kan användas istället eftersom vyn tenderar att göra prestandan dålig
(11) Använd UNION ALL mot UNION om du vet att data som hämtas inte kommer att ha dubbletter av rader
( 12) Använd tips för att optimera genomförandeplanen. Ibland kan ledtråd användas för att ändra exekveringsplanen för frågan så att den tar den mest optimala vägen.
I vissa fall skapar bindpeeking en dålig plan, så att i så fall ge nödvändiga tips för att fixa planen för att få bra prestanda varje gång
De vanligaste tipsen är
/*+ LEADING (tabellalias) */ anger tabell som ska börja gå med
/*+ FIRST_ROWS */ mycket bra för online skärmar – gynnar NESTADE LOOPAR
/*+ INDEX ( tabellalias.indexnamn) */ anger index som du vill använda. Obs:om index släpps och återskapas och namn ändras är tipset inte längre giltigt.
/*+ USE_NL (tabellalias1 tabellalias 2)*/ ber optimeraren att använda Nested Loop Join för de två angivna tabellerna
Undvik onödiga optimeringstips och använd dem med försiktighet
Det här är några av tipsen för att undvika problem och göra sql-inställningen. Sql-tuning är ett stort hav och du kan lära dig saker genom att bara träna. Lycka till!!
Läser också
https://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_1016.htm