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

6 problémových dotazů, které masivně zpomalují vaši databázi

Špatný výkon databáze je trnem v oku každého DBA. A není vždy snadné izolovat hlavní příčinu problémů s výkonem, což jen zvyšuje stres.

Vyladění databází SQL Server je skvělý způsob, jak vyřešit některé problémy s výkonem, ale nemusí být vždy zřejmé, kde byste měli začít proces optimalizace. Pokud vyloučíte místo na disku, paměť a další zabijáky síťového a hardwarového výkonu a výkon vašeho SQL Serveru stále pokulhává, je čas se ponořit do vašich dotazů.

Neoptimalizované dotazy mohou způsobit nesčetné problémy s výkonem vašich systémů. Na druhou stranu je několik běžných chyb při dotazech odpovědných za snížení výkonu databáze.

Pokud vaše dotazy trpí některým z těchto šesti problémů, připravte se na seriózní ladění výkonu.

Problémový dotaz č. 1:Like výrazy s hlavními zástupnými znaky

Hlavní zástupné znaky brání MySQL ve využívání indexů a vynucují si úplné prohledání tabulky, i když jste indexovali pole v tabulce. Prohledávání všech řádků v tabulce výrazně zpomaluje doručování výsledků dotazu, takže pro zvýšení efektivity odstraňte hlavní zástupný znak.

Problémový dotaz č. 2:Neindexované sloupce používané v klauzulích „Kde“ a „Seskupit podle“

Indexování sloupců pomáhá rychleji vracet výsledky dotazů, protože eliminuje potřebu úplného prohledávání tabulky. Indexování také pomáhá třídit záznamy, když jsou vráceny, a zaručuje, že tyto záznamy jsou jednoznačně identifikovatelné, což je užitečné zejména v tabulkách s více než 10 řádky.

Pro trochu perspektivy zvažte spuštění příkazu „vysvětlení“ v analýze dotazů před a po indexování. To vám dá představu o tom, kolik řádků skenování jste si právě uložili.

Problémový dotaz č. 3:Líbí se mi prohlášení, která místo sjednocující klauzule používají operátor „nebo“

Spouštění dotazů pomocí porovnávacího operátoru „nebo“ na pole nebo sloupce v tabulce může být užitečné, ale příliš časté použití „nebo“ v klauzuli „kde“ je další rychlou cestou k úplnému prohledání tabulky.

Sjednocovací klauzule může urychlit běh SQL dotazu, zvláště pokud různé indexy optimalizují každou stranu dotazu. Sjednocovací operátor v podstatě vezme výsledky dvou rychlých indexovaných dotazů a sloučí je do jednoho.

Problémový dotaz č. 4:Vyhledávání pomocí zástupných znaků

Pokud jste uvízli v situaci, kdy potřebujete vyhledávat pomocí zástupných znaků, ale nechcete mít dopad na výkon, zkuste použít fulltextové vyhledávání MySQL. Fulltextové vyhledávání je podstatně rychlejší než vyhledávání pomocí zástupných znaků a při prohledávání velkých databází získáte další výhodu v podobě relevantnějších výsledků.

Problémový dotaz č. 5:Neoptimalizované schéma databáze

Výkon dotazů SQL můžete zlepšit pouze tehdy, pokud neoptimalizujete také schéma databáze. Zde je několik tipů na zlepšení:

Normalizovat tabulky

Redundance dat poškozuje výkon, proto se ujistěte, že v databázi zastupujete skutečnost pouze jednou. Pokud například odkazujete na zákazníka ve více než jedné tabulce, použijte „jméno_zákazníka“ pouze jednou a pro další odkazy použijte „ID_zákazníka“.

Používejte optimální datové typy

Některé důležité body, které je třeba pamatovat, pokud jde o datové typy:

  • Při navrhování tabulek je lepší kratší. Například použijte datový typ „TINYINT“ pro pole „user_id“ pro systémovou tabulku uživatelů s méně než 100 uživateli.
  • Pokud pole očekává hodnotu data, použijte datový typ „date_time“, abyste poté nemuseli převádět záznamy do formátu data.
  • MySQL funguje lépe s celočíselnými hodnotami než s textovými datovými typy, včetně varchar.

Vyhněte se hodnotám Null

Hodnoty Null ve sloupci mohou poškodit výsledky dotazu, takže možná budete muset přiřadit výchozí hodnotu pro pole, kde záznamy nevyžadují povinnou hodnotu.

Nepoužívejte příliš mnoho sloupců

Široké tabulky (více než 100 sloupců) vyžadují ke zpracování hodně CPU a zdrojů. Pokud nutně nemusíte zahrnout širokou tabulku, je lepší ji rozdělit na menší logické tabulky.

Optimalizovat spojení

Příkazy SQL s příliš mnoha spojeními (a spojeními s příliš mnoha tabulkami) negativně ovlivňují výkon. Střílejte na maximálně 12 spojení pro každý dotaz.

Problémový dotaz č. 6:Dotazy MySQL bez mezipaměti

Webové stránky a aplikace, které provádějí mnoho vybraných dotazů, budou mít prospěch z ukládání dotazů MySQL do mezipaměti. Ukládání dotazů MySQL do mezipaměti zrychluje výkon během operací čtení, protože ukládá výběrový dotaz do mezipaměti spolu s výslednou datovou sadou a načítá z paměti (nikoli z disku), pokud je dotaz proveden více než jednou.

Ladění výkonu je zásadní pro udržení vysoké dostupnosti vašich databází SQL Server a zajištění spokojenosti vašich koncových uživatelů. Ale bohužel není vždy hned zřejmé, kde je ladění nejvíce potřeba. Pokud jste odstranili zjevné síťové a hardwarové zdroje problémů s výkonem, přesuňte pozornost na své dotazy.

Pokud pracujete jako DBA jakkoli dlouho, pravděpodobně jste narazili na jeden (nebo všechny) z těchto problémových dotazů. Nyní, když víte, na co si dát pozor, buďte proaktivní ve své iniciativě ke zlepšení výkonu a opravte tyto běžné problémy s dotazy, abyste mohli sklízet plody optimalizace dotazů SQL Server.


  1. Jak převést časové razítko na datum a čas v MySQL?

  2. Postgres Error:Více než jeden řádek vrácený poddotazem použitým jako výraz

  3. Úvod do Azure Serverless

  4. Jump to Start Test-Driven Database Development (TDDD)