sql >> Databasteknik >  >> RDS >> Sqlserver

Favorittrick för att trimma prestanda

Här är den praktiska listan över saker jag alltid ger till någon som frågar mig om optimering.
Vi använder främst Sybase, men de flesta råden kommer att gälla över hela linjen.

SQL Server, till exempel, kommer med en mängd prestandaövervaknings-/justeringsbitar, men om du inte har något sådant (och kanske även om du har det) så skulle jag överväga följande...

99 % av problemen Jag har sett orsakas av att för många tabeller läggs i en join . Fixningen för detta är att göra halva joinen (med några av tabellerna) och cachelagra resultaten i en tillfällig tabell. Gör sedan resten av frågan med att gå med i den tillfälliga tabellen.

Frågeoptimeringschecklista

  • Kör UPDATE STATISTICS på de underliggande tabellerna
    • Många system kör detta som ett schemalagt veckojobb
  • Ta bort poster från underliggande tabeller (eventuellt arkivera de raderade posterna)
    • Överväg att göra detta automatiskt en gång om dagen eller en gång i veckan.
  • Återskapa index
  • Återskapa tabeller (bcp-data ut/in)
  • Dumpa / ladda om databasen (drastiskt, men kan åtgärda korruption)
  • Skapa nytt, mer lämpligt index
  • Kör DBCC för att se om det finns en möjlig korruption i databasen
  • Lås / dödläge
    • Se till att inga andra processer körs i databasen
      • Särskilt DBCC
    • Använder du rad- eller sidnivålåsning?
    • Lås tabellerna exklusivt innan du startar frågan
    • Kontrollera att alla processer har åtkomst till tabeller i samma ordning
  • Används index på rätt sätt?
    • Joins kommer bara att använda index om båda uttrycken är exakt samma datatyp
    • Index kommer endast att användas om de första fälten i indexet matchas i frågan
    • Används klustrade index där så är lämpligt?
      • intervalldata
      • WHERE-fältet mellan värde1 och värde2
  • Små Joins är trevliga Joins
    • Som standard kommer optimeraren bara att beakta tabellerna 4 åt gången.
    • Detta betyder att i kopplingar med fler än 4 tabeller har det en god chans att välja en icke-optimal frågeplan
  • Sluta föreningen
    • Kan du bryta sammanfogningen?
    • Förvälj främmande nycklar till en tillfällig tabell
    • Gör halva kopplingen och lägg resultaten i en tillfällig tabell
  • Använder du rätt typ av tillfällig tabell?
    • #temp tabeller kan fungera mycket bättre än @table variabler med stora volymer (tusentals rader).
  • Underhåll sammanfattningstabeller
    • Bygg med utlösare på de underliggande tabellerna
    • Bygg dagligen / varje timme / etc.
    • Skapa ad hoc
    • Bygg stegvis eller riv/bygg om
  • Se vad frågeplanen är med SET SHOWPLAN PÅ
  • Se vad som faktiskt händer med SET STATS IO ON
  • Tvinga fram ett index med hjälp av pragman:(index:myindex)
  • Tvinga fram tabellordningen med SET FORCEPLAN ON
  • Parametersniffning:
    • Dela upp lagrad procedur i 2
    • ringa proc2 från proc1
    • låter optimeraren välja index i proc2 om @parameter har ändrats av proc1
  • Kan du förbättra din hårdvara?
  • Vilken tid springer du? Finns det en lugnare tid?
  • Körs replikeringsserver (eller annan non-stop process)? Kan du avbryta det? Kör den tex. varje timme?


  1. Knee-Jerk Performance Tuning:Lägg bara till en SSD

  2. Lär dig databasdesign med SQL Server Management Studio (SSMS) – Del 2

  3. Plsql för att stava nummer (valuta) till italiensk valuta utan hårdkodat översättningsnummer

  4. Oracle-skärm mer än 24 timmar