Dátum publikácie: 20. január 2026
Autor: Peter Vícen
Kategória: Špecializované témy a prípadové štúdie / SQL optimalizácia
Čas čítania: 7 minút

Predstavte si situáciu: váš e-shop počas sezónnej špičky zamrzne práve vo chvíli, keď zákazník klikne na „Zaplatiť“. Alebo váš finančný riaditeľ čaká na mesačný report 45 minút, zatiaľ čo databázový server ide na 100 % výkonu a blokuje prácu ostatným zamestnancom.

To nie sú hypotetické scenáre. To je realita, s ktorou sa ako databázový konzultant stretávam pravidelne.

Mnoho firiem sa snaží riešiť pomalé databázy nákupom drahšieho hardvéru. Často je to však ako liať benzín do auta s deravou nádržou. Skutočným problémom nie je nedostatok pamäte RAM, ale neefektívne napísané SQL dotazy a chýbajúce alebo zle navrhnuté indexy.

V dnešnom článku vám na troch reálnych príkladoch z praxe ukážem, aký drastický rozdiel dokáže urobiť odborná optimalizácia dotazov – nielen v sekundách, ale aj v ušetrených eurách.

Prípadová štúdia č. 1: E-shop, ktorý nestíhal filtrovať produkty

Prvý príklad pochádza od klienta z oblasti e-commerce. Problém bol kritický: používatelia sa sťažovali na pomalé načítavanie produktov pri použití filtrov (napr. „Farba: modrá“ + „Veľkosť: M“ + „Cena: do 50 €“).

Východisková situácia

• Databáza: PostgreSQL
• Veľkosť tabuľky produktov: 2 milióny riadkov
• Priemerný čas odozvy pri filtrovaní: 5,2 sekundy

Problém

Analýza plánu vykonania dotazu (Query Execution Plan) odhalila, že databáza pri každom vyhľadávaní vykonávala tzv. full table scan – musela prečítať všetkých 2 milióny riadkov, aby našla tých pár, ktoré vyhovovali podmienkam. Pre najpoužívanejšie kombinácie filtrov chýbali vhodné indexy.

Riešenie

Nasadili sme stratégiu efektívneho využitia indexov:

• vytvorili sme kompozitné (viacstĺpcové) indexy, ktoré pokrývali najčastejšie kombinácie filtrov,
• upravili sme dotazy tak, aby indexy dokázali využiť (napr. poradie stĺpcov v podmienkach),
• zároveň sme sa vyhli scenárom, kde by indexy výkonu skôr uškodili (napr. pri nadmernej fragmentácii).

Výsledky

Metrika	Pred optimalizáciou	Po optimalizácii	Zlepšenie
Čas odozvy	5 200 ms (5,2 s)	85 ms	~60-krát rýchlejšie
Zaťaženie CPU	80 – 90 %	5 – 10 %	dramatický pokles
Používateľská skúsenosť	Frustrácia, odchody	Takmer okamžité načítanie	vyššia konverzia

Biznis dopad: okamžitá odozva viedla k zníženiu miery okamžitých odchodov (bounce rate) o 15 % už v prvom týždni po nasadení. Menej čakania = viac dokončených objednávok.

Prípadová štúdia č. 2: Nočná mora firemného reportingu

Druhý klient, stredne veľká logistická firma, bojoval s generovaním komplexných reportov. Ich systém potreboval každé ráno vypočítať efektivitu trás a náklady na palivo pre desiatky vozidiel.

Východisková situácia

• Databáza: Microsoft SQL Server
• Čas generovania reportu: 38 minút
• Dopad na systém: počas generovania bol systém pre ostatných používateľov takmer nepoužiteľný (locking, blokovanie transakcií).

Problém

Pri hĺbkovej analýze som zistil, že pôvodný kód používal neefektívne kurzory a množstvo vnorených poddotazov (subqueries), ktoré sa spúšťali pre každý riadok zvlášť. Typický príklad kódu, ktorý síce funguje, ale zabíja výkon.

Riešenie

Aplikoval som techniky prepisovania dotazov (Query Rewriting Techniques):

• vnorené poddotazy sme nahradili efektívnejšími JOIN operáciami,
• na analytické výpočty sme použili window funkcie, ktoré sú na tieto operácie optimalizované,
• report sme presunuli na read-only repliku, aby neblokoval hlavnú produkčnú databázu.

Výsledky

Metrika	Pred optimalizáciou	Po optimalizácii	Zlepšenie
Trvanie generovania	38 minút	1 minúta 45 sekúnd	~95 % úspora času
Blokovanie ostatných	Kritické (deadlocky, zamŕzanie systému)	Žiadne	stabilita systému

Biznis dopad: manažéri majú dáta k dispozícii pred rannou poradou, nie po nej. IT oddelenie prestalo dostávať sťažnosti na zamŕzanie systému a server má dostatočnú rezervu aj pri ďalšom raste firmy.

Prípadová štúdia č. 3: Migrácia na cloud a „nafúknutá“ databáza

Tretí prípad sa týkal klienta, ktorý prechádzal na cloudové riešenie a potreboval znížiť náklady na úložisko a prevádzku. Databáza rástla exponenciálne, no výkon klesal.

Východisková situácia

• Objem dát: 4 TB
• Problémy:
  • extrémne pomalé zálohovanie,
  • vysoké náklady na cloud hosting,
  • zhoršujúci sa výkon pri práci s aktuálnymi dátami.

Jadrom problému nebol jeden konkrétny dotaz, ale nevhodný fyzický dizajn databázy (physical design). Tabuľky používali nevhodné dátové typy (napr. NVARCHAR(MAX) pre krátke texty) a chýbala stratégia archivácie starých dát.

Riešenie

Projekt si vyžadoval komplexný prístup k modelovaniu a optimalizácii:

• Výber správnych dátových typov: optimalizácia veľkosti stĺpcov pre lepší výkon a menšiu spotrebu úložiska.
• Partitioning tabuliek: rozdelenie veľkých tabuliek na menšie časti podľa dátumu, čo zrýchlilo prístup k aktuálnym dátam a zjednodušilo údržbu.
• Údržba indexov: nastavenie automatizovaných procesov na defragmentáciu indexov a pravidelné štatistiky.

Výsledky

• Veľkosť databázy sa zmenšila približne o 35 % (bez straty dát – len optimalizáciou štruktúry).
• Čas zálohovania sa skrátil z 8 hodín na 4,5 hodiny.
• Náklady na cloudovú infraštruktúru klesli o stovky eur mesačne.

Čo si z toho odniesť?

Optimalizácia SQL dotazov a databáz nie je len „technická údržba“. Je to priama investícia do:

• Škálovateľnosti: váš systém zvládne násobne viac používateľov bez nutnosti kupovať nové servery.
• Používateľskej spokojnosti: nikto nechce čakať na načítanie stránky 5 sekúnd.
• Úspory nákladov: efektívny kód spotrebuje menej CPU a RAM – a za tieto zdroje v cloude platíte každý mesiac.

Často sa stretávam s tým, že vývojári vedia napísať kód, ktorý funguje, ale nemajú kapacity alebo hlboké znalosti na to, aby napísali kód, ktorý funguje efektívne pod veľkou záťažou. A presne tam vstupuje do hry expertíza databázového konzultanta.

Vidíte vo vyššie uvedených príkladoch problémy aj vo vašej firme? Máte pocit, že vaša databáza vás brzdí v raste?

Nečakajte, kým systém spadne. Poďme sa pozrieť na vaše dáta.

👉 [Dohodnite si nezáväznú konzultáciu] a zistite, koľko výkonu sa skrýva vo vašej súčasnej infraštruktúre. Často stačí len vedieť, kam „klepnúť kladivkom“.