Dålig databasprestanda är en nagel i ögonen på varje DBA. Och det är inte alltid lätt att isolera grundorsaken till prestationsproblem, vilket bara ökar stressen.
Att justera dina SQL Server-databaser är ett bra sätt att lösa några av dina prestandaproblem, men det kanske inte alltid är självklart var du ska börja optimeringsprocessen. Om du utesluter diskutrymme, minne och andra prestandadödare för nätverk och hårdvara, och din SQL Server-prestanda fortfarande släpar efter, är det dags att gräva i dina frågor.
Ooptimerade frågor kan orsaka otaliga prestandaproblem för dina system. På den ljusa sidan är några vanliga frågemisstag ansvariga för huvuddelen av databasprestandaförsämringen.
Om dina frågor lider av något av dessa sex problem, gör dig redo för en seriös prestandajustering.
Problemfråga nr 1:Gilla uttryck med ledande jokertecken
Ledande jokertecken hindrar MySQL från att använda index, vilket tvingar fram en fullständig tabellsökning även om du har indexerat ett fält i tabellen. Genom att skanna alla rader i en tabell saktar leveransen av dina frågeresultat avsevärt ner, så eliminera det ledande jokertecken för att förbättra effektiviteten.
Problemfråga nr 2:Icke-indexerade kolumner som används i klausulerna "Var" och "Grupp efter"
Indexering av kolumner hjälper till att returnera frågeresultat snabbare eftersom det eliminerar behovet av fullständiga tabellgenomsökningar. Indexering hjälper också till att sortera poster när de returneras och garanterar att dessa poster är unikt identifierbara, vilket är särskilt användbart i tabeller med fler än 10 rader.
För lite perspektiv, överväg att köra en "förklara"-sats i din frågeanalys före och efter indexering. Detta ger dig en uppfattning om hur många rader med skanning du just sparat själv.
Problemfråga nr 3:Liknande uttalanden som använder "eller"-operatören istället för en unionsklausul
Att köra frågor med jämförelseoperatorn "or" på fält eller kolumner i en tabell kan vara användbart, men att använda "or" för ofta i en "where"-sats är ytterligare ett snabbt spår till en fullständig tabellsökning.
En unionsklausul kan få SQL-frågan att köras snabbare, särskilt om olika index optimerar varje sida av frågan. I huvudsak tar den fackliga operatören resultaten av två snabba, indexerade frågor och slår samman dem till en.
Problemfråga nr 4:Jokerteckensökningar
Om du har fastnat i en situation där du behöver söka med jokertecken men du inte vill ta prestandaträffen, försök använda en MySQL-fulltextsökning. Fulltextsökningar är betydligt snabbare än att söka med jokertecken, och du får den extra fördelen av mer relevanta resultat när du söker i stora databaser.
Problemfråga nr 5:Ooptimerat databasschema
Du kan bara förbättra SQL-frågeprestanda så mycket om du inte också optimerar ditt databasschema. Här är några tips för förbättringar:
Normalisera tabeller
Dataredundans skadar prestandan, så se till att endast representera ett faktum en gång i databasen. Om du till exempel hänvisar till en kund i mer än en tabell, använd bara "customer_name" en gång och använd sedan "customer_ID" för efterföljande referenser.
Använd optimala datatyper
Några viktiga punkter att komma ihåg när det gäller datatyper:
- Kortare är bättre när man designar tabeller. Använd till exempel datatypen "TINYINT" för fältet "user_id" för en systemanvändartabell med färre än 100 användare.
- Använd en datatyp "date_time" om ett fält förväntar sig ett datumvärde så att du inte behöver konvertera posterna till datumformat i efterhand.
- MySQL fungerar bättre med heltalsvärden än med textdatatyper, inklusive varchar.
Undvik nollvärden
Nullvärden i en kolumn kan skada dina frågeresultat, så du kan behöva tilldela ett standardvärde för fält där poster inte kräver ett obligatoriskt värde.
Använd inte för många kolumner
Breda tabeller (mer än 100 kolumner) kräver mycket CPU och resurser att bearbeta. Om du inte absolut måste inkludera ett brett bord är det bättre att dela upp det i mindre, logiska tabeller.
Optimera anslutningar
SQL-satser med för många kopplingar (och kopplingar med för många tabeller) påverkar prestanda negativt. Ta inte fler än 12 anslutningar för varje fråga.
Problemfråga nr 6:Un-cachade MySQL-frågor
Webbplatser och applikationer som utför många utvalda frågor kommer att dra nytta av att cachelagra MySQL-frågor. MySQL-frågecachning påskyndar prestandan under läsoperationer eftersom den cachar urvalsfrågan tillsammans med den resulterande datamängden och hämtar från minnet (inte disken) om frågan exekveras mer än en gång.
Prestandajustering är avgörande för att upprätthålla hög tillgänglighet för dina SQL Server-databaser och för att säkerställa att dina slutanvändare är nöjda. Men tyvärr är det inte alltid omedelbart uppenbart var trimningen behövs mest. Om du har eliminerat de uppenbara nätverks- och hårdvarukällorna för prestandaproblem, flytta ditt fokus till dina frågor.
Om du har arbetat som en DBA under en längre tid har du troligen stött på en (eller alla) av dessa problemfrågor. Nu när du vet vad du ska hålla utkik efter, var proaktiv i ditt prestationsförbättringsinitiativ och korrigera dessa vanliga frågeproblem så att du kan skörda frukterna av SQL Server-frågeoptimering.