sql >> Databáze >  >> RDS >> Sqlserver

Oblíbené triky pro ladění výkonu

Zde je praktický seznam věcí, které vždy předám někomu, kdo se mě ptá na optimalizaci.
Používáme hlavně Sybase, ale většina rad bude platit plošně.

SQL Server například přichází s řadou bitů pro monitorování / ladění výkonu, ale pokud nic takového nemáte (a možná i když máte), pak bych zvážil následující...

99 % problémů Viděl jsem, že jsou způsobeny vložením příliš mnoha stolů do spojení . Řešením je provést polovinu spojení (s některými tabulkami) a uložit výsledky do mezipaměti v dočasné tabulce. Potom proveďte zbytek spojení dotazu na této dočasné tabulce.

Kontrolní seznam optimalizace dotazů

  • Spusťte UPDATE STATISTICS na podkladových tabulkách
    • Mnoho systémů to spouští jako plánovaná týdenní úloha
  • Odstraňte záznamy z podkladových tabulek (smazané záznamy případně archivujte)
    • Zvažte automatické provádění jednou denně nebo jednou týdně.
  • Znovu sestavit indexy
  • Znovu sestavit tabulky (data BCP out/in)
  • Vypsat/znovu načíst databázi (drastické, ale může opravit poškození)
  • Vytvořte nový, vhodnější index
  • Spusťte DBCC a zjistěte, zda je v databázi možné poškození
  • Zámky / uváznutí
    • Zajistěte, aby v databázi neběžely žádné další procesy
      • Zejména DBCC
    • Používáte zamykání na úrovni řádku nebo stránky?
    • Před zahájením dotazu výhradně uzamkněte tabulky
    • Zkontrolujte, zda všechny procesy přistupují k tabulkám ve stejném pořadí
  • Používají se indexy správně?
    • Spojení použije index pouze v případě, že oba výrazy jsou přesně stejného datového typu
    • Index bude použit pouze v případě, že se první pole indexu shodují v dotazu
    • Používají se tam, kde je to vhodné, seskupené indexy?
      • údaje o rozsahu
      • pole WHERE mezi hodnotou1 a hodnotou2
  • Malá spojení jsou pěkná spojení
    • Ve výchozím nastavení bude optimalizátor brát v úvahu pouze tabulky 4 najednou.
    • To znamená, že ve spojeních s více než 4 tabulkami má velkou šanci zvolit neoptimální plán dotazů.
  • Rozdělit připojení
    • Můžete spojení přerušit?
    • Předvyberte cizí klíče do dočasné tabulky
    • Udělejte polovinu spojení a umístěte výsledky do dočasné tabulky
  • Používáte správný druh dočasné tabulky?
    • #temp tabulky mohou fungovat mnohem lépe než @table proměnné s velkými objemy (tisíce řádků).
  • Udržovat souhrnné tabulky
    • Vytvářejte pomocí spouštěčů na podkladových tabulkách
    • Vytvářejte denně / každou hodinu / atd.
    • Vytvářejte ad-hoc
    • Budujte postupně nebo bourejte/přestavujte
  • S SET SHOWPLAN ON se podívejte, jaký je plán dotazů
  • Pomocí funkce SET STATS IO ON se podívejte, co se skutečně děje
  • Vynucení indexu pomocí pragma:(index:myindex)
  • Vynucení pořadí tabulek pomocí SET FORCEPLAN ON
  • Sniffování parametrů:
    • Rozdělit uloženou proceduru na 2
    • volání proc2 z proc1
    • umožňuje optimalizátoru vybrat index v proc2, pokud byl @parametr změněn proc1
  • Můžete vylepšit svůj hardware?
  • V kolik běžíš? Existuje klidnější období?
  • Běží replikační server (nebo jiný nepřetržitý proces)? Můžete to pozastavit? Spusťte to např. hodinově?


  1. Použití funkce Oracle to_date pro řetězec data s milisekundami

  2. Psaní velkých písmen jmen osob v programování

  3. Jak odstranit úvodní a koncové mezery v SQL Server – TRIM()

  4. TDS Server – Použití příkazů Transact-SQL (T-SQL) pro práci s daty Salesforce na SQL Server