PostgreSQL - optimalizace dotazů

Když děláme násobky dotazy V komplexním systému mnohdy nebereme vhodnou cestu k dosažení optimálního výkonu na úrovni databáze, při současném technologickém pokroku a výpočetním výkonu, který často vidíme na našich serverech, si můžeme myslet, že optimalizace databáze je věcí minulosti.
To nemůže být dále od pravdy, navzdory pokroku v síle zařízení jsou databáze zásadní pro výkon aplikací, a proto dobře napsaný a vysoce optimalizovaný dotaz může znamenat několik sekund zatížení, které ukládá systém, vynásobíme -li to počtem souběžných uživatelů, uvidíme, jak se plýtvá náklady a energií.
Optimalizujte dotazy
Nejlepší způsob, jak zlepšit výkon našich databází, je začít s dobře napsanými dotazy, mnohokrát zjistíme, že dotazy nejsou dobře napsané, protože nejsou tak optimalizované, jak by měly být, existuje mnoho příčin, jedna z nich je opětovné použití bez znalosti kódu; Tím myslíme, že pokud jsme v určitém okamžiku vytvořili dotaz, který pro nás pracuje s příponou levé připojení Budeme jej nadále používat při zvyšování počtu tabulek, které je třeba konzultovat, při jeho úpravách a změně některých klauzulí vnitřní spojení Mohlo by to zkrátit cestu a ušetřit spotřebu procesoru.
SQL je jazyk, který je sice dobře čitelný, ale má mnoho aspektů a mnoho variací, které nám umožňují dělat něco, co funguje nejlepším a nejhorším způsobem. Je na nás, abychom věděli, jak zjistit, zda naše řešení patří kategorie nebo jiné.
Abychom věděli, že jsme na správné cestě, je třeba aktualizovat jednu z nejdůležitějších věcí, to znamená, že nemůžeme pokračovat v kódování v SQL v rámci PostgreSQL jako by to byla první verze, když jsme v verze 9.
O používání dílčích dotazů
Toto je jedna z nejčastějších chyb, kterých se dopouštíme, a to je, že dotaz považujeme za sadu částí, které do sebe dáváme dohromady, dokud nezískáme konečný výsledek, nicméně toto chování má velký dopad na výkon naší databáze.
Podívejme se na příklad tohoto typického chování:

 VYBRAT trakt_id, (VYBRAT COUNT (*) Z census.facts jako F WHERE F.tract_id = T.tract_id) As num_facts, (SELECT COUNT (*) FROM census.lu_fact_types As Y WHERE Y.fact_type_id IN (SELECT fact_type_id FROM census. fakta F KDE F.tract_id = T.tract_id)) As num_fact_types FROM census.lu_tracts As T; 

Nyní, pokud vidíme graf VYSVĚTLIT Z tohoto dotazu si uvědomíme, jak nákladné je to udělat tímto způsobem:

ZVĚTŠIT

Jak vidíme, v tomto dotazu máme několik bodů, které jsou překážkou, kromě všech dat, která je třeba neefektivně přesouvat, je proto přepíšeme optimálnějším způsobem a porovnáme s novým grafem VYSVĚTLIT.

 VYBRAT T.tract_id, COUNT (f.fact_type_id) jako num_facts, COUNT (DISTINCT fact_type_id) jako num_fact_types FROM census.lu_tracts As T LEFT JOIN census.facts As F ON T.tract_id = F.tract_id GROUP BY T.tract_id; 

V této nové verzi našeho dotazu se vyhýbáme používání poddotazů, místo toho děláme ekvivalent s levé připojení Y skupina vytvořenáPokud vidíme graf, můžeme poznat rozdíl.

ZVĚTŠIT

Můžeme vidět, jak byl způsob získání našeho výsledku mnohem kratší, což nám dává vyšší výkon, tím nemyslíme, že musíme vyloučit dílčí dotazy našich pracovních nástrojů, ale spíše si musíme být vědomi toho, že mohou existují lepší cesty k tomu, co v tuto chvíli možná navrhujeme.Líbil se vám tento návod a pomohl mu?Autora můžete odměnit stisknutím tohoto tlačítka, čímž mu dáte kladný bod