• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

Na závěr si zvykněte na pravidelné sledování pomalých dotazů. Většina databází umožňuje zapnout logování pomalých dotazů. Jakmile nějaký najdete, projděte si výše uvedené body. Někdy pomůže i rozdělení velké tabulky na menší party. Ale ať děláte cokoli, vždy testujte na reálných datech – to, co platí pro malou tabulku, nemusí fungovat pro miliony řádků.

Prvním krokem je kontrola, zda dotaz skutečně využívá indexy. Použijte příkaz EXPLAIN a sledujte sloupec type a key. Pokud vidíte ALL, znamená to plný průchod tabulkou. To je obvykle největší brzda. Index by měl pokrývat sloupce, které používáte úložné prostory v malém bytě podmínce WHERE, JOIN a ORDER BY. Nezapomínejte, že pořadí sloupců v indexu má vliv – pokud máte index (a, b), dotaz s podmínkou na b sice index využije, ale neefektivně. Lepší je sloupce v indexu řadit podle selektivity.

Nakonec nezapomeňte na to, že jednotná konfigurace není cíl, ale prostředek. Pokud zjistíte, že tým tráví více času údržbou konfigurace než samotným kódem, změňte ji. Vyplatí se investovat do interní dokumentace, která vysvětlí, proč jsou určité hodnoty nastavené tak, jak jsou. A pokud máte v týmu nováčky, zkuste IDE, které umožňuje onboarding bez manuálního nastavování – třeba tím, že konfigurace obsahuje i vysvětlující komentáře. V konečném důsledku je nejlepší IDE to, které se stane neviditelným nástrojem, protože se všichni soustředí na řešení problému, ne na ladění prostředí.

Optimalizace SQL dotazů není jen o přidání indexu. Skutečný výkon se odvíjí od kombinace správného návrhu tabulek, psaní dotazů a pochopení toho, jak databáze pracuje s daty. Nejčastější chybou je řešit až následky – tedy když je systém pomalý. Přitom stačí dodržovat několik zásad, které zvládnete aplikovat hned.

Důležitou roli hraje i pořadí načítání prvků. Text a hlavní obsah by se měly zobrazit okamžitě, až poté se dočítají doplňky. Toho dosáhnete tak, že kritické styly vložíte přímo do stránky a další soubory načtete až po jejím vykreslení. Stejně tak můžete odložit načtení obrázků, které nejsou hned vidět. Typickou chybou je nahrát na stránku velké video, které se spustí automaticky – to okamžitě zpomalí celý web. Vždy nechte videonahrát až po kliknutí.

Optimalizace se netýká jen samotného příkazu, ale i struktury dat. Normalizace je dobrá pro konzistenci, ale příliš mnoho spojení (JOIN) může být pomalé. V takovém případě zvažte denormalizaci – přidání redundantních sloupců, které odstraní drahé spojení. Mějte ale na paměti, že to zvyšuje složitost při zápisu. Kompromisem je použití materiálizovaných pohledů nebo předpočítaných souhrnů pro často používané agregace. Pravidelně také aktualizujte statistiky, aby optimalizátor měl správné informace o distribuci dat.

Na závěr: pokud se přistihnete, že řešíte konflikty častěji než samotné psaní kódu, je to signál, že váš proces je špatně nastavený. Zkuste zkrátit životnost větví, častěji rebase a hlavně nezanedbávejte komunikaci s ostatními členy týmu. Když dva lidé mění stejnou část kódu, je vždy lepší si to říct předem, než spoléhat na to, že verzovací nástroj vše vyřeší. Dobrý verzovací workflow není o tom, jak nástroj používat, ale o tom, jak se vyhnout situacím, kdy vás nástroj přestane bavit.

Rychlost načítání webu rozhoduje o tom, jestli návštěvník zůstane, nebo odejde ke konkurenci. I když se zdá, že jde o technickou záležitost, běžně ji ovlivníte bez zásahu vývojáře. Základním krokem je změřit si skutečný čas načtení – ne na svém počítači, ale v reálných podmínkách. Použijte nástroj, který simuluje pomalé připojení a slabší mobilní zařízení. Z výsledku zjistíte, co je třeba řešit jako první.

Základem výkonu jsou indexy. Bez správného indexu musí databáze procházet celou tabulku, což je u velkých objemů dat neúnosné. Při návrhu indexů myslete na to, že je potřebujete přesně pro podmínky ve WHERE, spojení (JOIN) a řazení (ORDER BY). Častou chybou je vytváření indexů na sloupcích, které se v dotazech téměř nepoužívají, nebo naopak vytváření příliš mnoha indexů, které zpomalují zápisy. Měřte pomocí EXPLAIN, jak se dotaz vykonává, a sledujte, zda databáze index skutečně používá.

Další častou chybou je použití SELECT *, které tahá zbytečné sloupce. Databáze pak přenáší data, která nikdo nepotřebuje, a to zbytečně zatěžuje síť i paměť. Vyberte jen potřebné sloupce. Tím se také zmenší velikost výsledku a zjednoduší se použití pokrývajících indexů – když index obsahuje všechny vybrané sloupce, nemusí se sahat do tabulky.

Dalším problémem je dotazování na velké množství sloupců, které v danou chvíli nepotřebujete. Místo SELECT * vracejte pouze nezbytné sloupce. Snižuje se tím objem přenášených dat a paměťová náročnost. Když potřebujete jen počty nebo součty, neposílejte do aplikace všechny řádky, ale nechte agregaci na databázi. Také si dejte pozor na neúmyslné kartézské součiny – vynechání JOIN podmínky může znásobit počet řádků a výkon katastrofálně spadnout.