sql >> Databasteknik >  >> RDS >> Sqlserver

Tips för att minska din SQL Server-komplexitet

Komplexa SQL-frågor är utmärkta för att göra databassökningar mycket specifika och flexibla, men de kan också vara svåra att förstå och nästan omöjliga att felsöka – och du kan lika gärna glömma att återanvända dem.

När frågor går utöver dina vanliga SELECT- och WHERE-kommandon kan du till och med upptäcka att SQL Server-prestanda börjar bli lidande eftersom frågeoptimerare har problem med att bearbeta långa, komplexa frågor.

Om du märker att dina SQL-frågor använder ett för stort antal komplexa kopplingar och underfrågor, kapslar frågor i WHERE-satser och förlitar sig på många AND- och OR-satser, är det förmodligen ett bra tillfälle att ta ett steg tillbaka och leta efter sätt att minimera en del av komplexiteten.

Tips för att minimera SQL Server-frågakomplexiteten

Som vi nämnde ovan älskar SQL Server-frågeoptimerare inte komplexa SQL-frågor. Här är fem sätt att göra dina frågor mindre komplexa så att de kan optimeras för förbättrad prestanda.

1. Eliminera ELLER-klausuler när det är möjligt

Det enklaste sättet att göra frågor mindre komplexa är att eliminera ELLER-satser närhelst det är möjligt. Eftersom OR är inkluderande måste SQL Server behandla varje komponent i klausulen separat, vilket verkligen saktar ner operationerna.

När det inte är möjligt att ta bort OR, är det näst bästa alternativet att dela upp långa, komplexa frågor i mindre. Det verkar lite kontraintuitivt att bearbetning av fler frågor är snabbare än att bearbeta en, men när det kommer till ELLER är det bättre att du går med flera frågor.

2. Finjustera strängsökningar

SQL Server gör många saker bra, men fuzzy strängsökningar är inte en av dem. Sökningar med jokertecken, särskilt på stora bord, är ineffektiva och dåliga för prestanda.

Det finns några justeringar du kan tillämpa på strängsökningar som hjälper till att minimera effekten på prestanda.

  • Använd en ledande strängsökning istället för en jokerteckensökning (dvs. ändra "%For%" till "For%")
  • Använd filter som datum eller tid på frågan för att minska storleken på data innan du kör strängsökningen
  • Tillämpa fulltextindexering för att generera index som möjliggör flexibel strängsökning i textkolumner

3. Se upp för stora skrivoperationer

Stora skrivoperationer orsakar konflikter och genererar många loggfiler. Om det inte är markerat kan stora skrivoperationer blockera resurser från användare och skapa latensproblem samt fylla transaktionsloggar eller till och med fysisk lagring.

Eftersom du inte alltid kan undvika stora skrivoperationer, var medveten om när du kör dem (ju mindre upptagen servern är, desto bättre) eller minska antalet rader som ändras per operation för att minimera risken för konflikter.

4. Rensa upp index

Index är en av de största bovarna när det kommer till dålig prestanda, men när du försöker optimera komplexa SQL-frågor kräver index några speciella överväganden.

SQL Server har flera verktyg som låter dig veta när saknade index påverkar frågeprestanda. Men innan du hoppar in och börjar lägga till index måste du avgöra om det ytterligare indexet kommer att förbättra frågan tillräckligt för att göra det värt ansträngningen. Till exempel, om frågan körs 1 miljon gånger om dagen och indexet förbättrar den med 25 procent, så är det förmodligen värt det. Om frågan sällan används kanske den inte är meningsfull.

Några andra saker att tänka på innan du börjar lägga till index är om befintliga index kan justeras för att täcka detta användningsfall utan att lägga till ett nytt och om detta index redan finns men optimeraren ignorerar det av någon anledning.

Andra sätt som index kan påverka frågeprestanda är över- eller underindexeringstabeller och tabeller som saknar ett klustrat index eller en primärnyckel. Att lösa dessa problem kommer att hjälpa till med komplexa SQL-frågor.

5. Fortsätt räkna ned tabell

Varje gång du lägger till en tabell i en fråga blir frågan mer komplex. Överdrivna tabeller resulterar ofta i dåliga genomförandeplaner eftersom frågeoptimeraren inte kan fungera effektivt.

Om du märker att en komplex fråga fungerar dåligt och har många tabeller, kan detta vara en av de tillfällen då att dela upp frågan i mindre frågor är det bästa valet eftersom det kommer att lindra en del av bördan för optimeraren.

Verktyg för prestandajustering kan hjälpa till att minimera SQL Server-komplexiteten

När komplexa frågor försämrar frågeoptimeraren, får du ofta en ineffektiv exekveringsplan, och prestandan blir lidande. Utöver tipsen ovan är verktyg för prestandajustering en värdefull resurs för att minimera SQL Server-frågakomplexiteten och optimera prestanda.

Nedan finns några av funktionerna att leta efter när du undersöker lösningar för prestandajustering.

SQL Server Execution Plan Analysis

Inställningsverktyget bör analysera din exekveringsplan och avgöra vad som behöver ändras för att SQL Server ska kunna utföra operationer mer effektivt.

SQL Server Execution Plan Visualization

Trimverktyget bör presentera exekveringsplanen på ett sätt som är lätt att förstå och hjälper dig att lokalisera de operationer som saktar ner exekveringen.

Automatisk SQL-optimering

Inställningsverktyget bör analysera din SQL och sedan automatiskt skriva om den tills den når maximal förbättringstid.

Jämförelse av optimerade och ursprungliga SQL-satser

Inställningsverktyget bör markera ändringar i SQL-satsen så att du kan jämföra de ursprungliga och optimerade versionerna innan du distribuerar ändringar.

Jämförelse av SQL Server Execution Plans

Inställningsverktygen bör ge en jämförelse av de ursprungliga och optimerade utförandeplanerna så att du vet vad som ändrades mellan versionerna.

Statistiskt bevis

Ditt inställningsverktyg bör tillhandahålla data som visar varför den optimerade SQL-funktionen körs snabbare än den ursprungliga SQL-satsen.

Komplexa SQL Server-frågor kan ha en negativ inverkan på systemets prestanda. Använd dessa tips och en högkvalitativ lösning för prestandajustering för att rensa upp komplexiteten och optimera effektiviteten i din SQL-fråga.


  1. Använda RStudio med en icke-systemversion av unixODBC Driver Manager

  2. Filtrerade index och forcerad parametrering (redux)

  3. SQL Server GUID sorteringsalgoritm. Varför?

  4. Ställa in MySQL root-användarlösenordet på OS X