Yndlingstricks til tuning af ydeevne

Her er den handy-dandy liste over ting, jeg altid giver til nogen, der spørger mig om optimering.
Vi bruger hovedsageligt Sybase, men de fleste råd vil gælde overalt.

SQL Server, for eksempel, kommer med et væld af ydelsesovervågning / tuning bits, men hvis du ikke har noget lignende (og måske endda hvis du har), så vil jeg overveje følgende...

99 % af problemerne Jeg har set er forårsaget af at for mange tabeller sættes i en join . Rettelsen til dette er at lave halvdelen af ​​joinforbindelsen (med nogle af tabellerne) og cache resultaterne i en midlertidig tabel. Udfør derefter resten af ​​forespørgslen ved at slutte sig til den midlertidige tabel.

Forespørgselsoptimeringstjekliste

• Kør UPDATE STATISTICS på de underliggende tabeller
  • Mange systemer kører dette som et planlagt ugentligt job
• Slet poster fra underliggende tabeller (arkivér eventuelt de slettede poster)
  • Overvej at gøre dette automatisk én gang om dagen eller én gang om ugen.
• Genopbyg indekser
• Genopbyg tabeller (bcp-data ud/ind)
• Dump / Genindlæs databasen (drastisk, men kan muligvis løse korruption)
• Byg nyt, mere passende indeks
• Kør DBCC for at se, om der er mulig korruption i databasen
• Låse / dødlåse
  • Sørg for, at ingen andre processer kører i databasen
    • Især DBCC
  • Bruger du række- eller sideniveaulåsning?
  • Lås udelukkende tabellerne, før du starter forespørgslen
  • Tjek, at alle processer tilgår tabeller i samme rækkefølge
• Bliver indekser brugt korrekt?
  • Joins vil kun bruge indeks, hvis begge udtryk er nøjagtig den samme datatype
  • Indeks vil kun blive brugt, hvis det eller de første felter på indekset matches i forespørgslen
  • Bruges grupperede indekser, hvor det er relevant?
    • områdedata
    • WHERE-feltet mellem værdi1 og værdi2
• Små Joins er gode Joins
  • Som standard vil optimeringsværktøjet kun overveje tabellerne 4 ad gangen.
  • Det betyder, at i joinforbindelser med mere end 4 tabeller, har det en god chance for at vælge en ikke-optimal forespørgselsplan
• Opdel tilslutningen
  • Kan du bryde sammenføjningen?
  • Forudvælg fremmednøgler i en midlertidig tabel
  • Gør halvdelen af ​​joinforbindelsen, og læg resultaterne i en midlertidig tabel
• Bruger du den rigtige form for midlertidig tabel?
  • #temp tabeller kan fungere meget bedre end @table variabler med store volumener (tusindvis af rækker).
• Vedligehold oversigtstabeller
  • Byg med triggere på de underliggende tabeller
  • Byg dagligt / hver time / osv.
  • Byg ad hoc
  • Byg trinvist eller nedriv/genopbyg
• Se, hvad forespørgselsplanen er med SET SHOWPLAN TIL
• Se, hvad der rent faktisk sker med SET STATS IO ON
• Tving et indeks ved hjælp af pragmaen:(indeks:minindeks)
• Tving bordrækkefølgen ved at bruge SET FORCEPLAN TIL
• Parametersniffing:
  • Opdel lagret procedure i 2
  • kald proc2 fra proc1
  • giver optimering mulighed for at vælge indeks i proc2, hvis @parameter er blevet ændret af proc1
• Kan du forbedre din hardware?
• Hvad tid løber du? Er der en roligere tid?
• Kører replikeringsserver (eller anden non-stop proces)? Kan du suspendere det? Kør det fx. hver time?