SQL optimalizace — pojmy a praxeSQL optimalizace: rychlejší dotazy, nižší cloud náklady
Často hledané pojmy okolo ladění SQL výkonu — od execution planů a indexů přes statistiky a partitioning až po Snowflake/BigQuery cost optimization.
Co je SQL optimalizace
SQL optimalizace je proces analýzy a úpravy dotazů, schématu a infrastruktury tak, aby dotazy běžely rychleji a levněji. Zahrnuje rewriting SQL, návrh indexů, partitioning, aktualizaci statistik, hardware tuning i přechod na vhodnější enginy (OLAP vs OLTP). Cíl: nižší latence (p95), nižší CPU/I/O a u cloudu nižší compute náklady.
Execution plan (EXPLAIN)
Execution plan je strom operátorů (Seq Scan, Index Scan, Hash Join, Nested Loop, Sort), kterým optimalizér plánuje provést dotaz. EXPLAIN ANALYZE v PostgreSQL, SHOW PLAN_ALL v SQL Serveru, EXPLAIN PLAN v Oracle nebo Query Profile ve Snowflake odhalí, kde se ztrácí čas — full table scan, špatný join order, missing index, spilled hash tabulka.
Indexy — B-Tree, Hash, GIN, columnstore
B-Tree index pokrývá většinu equality a range dotazů. Hash index je rychlejší pro čistě equality lookups. GIN/GiST indexy v PostgreSQL pro JSON, full-text a geometrii. Columnstore indexy (SQL Server, ClickHouse) pro analytické agregace. Pro Snowflake/BigQuery klasické indexy neexistují — místo nich clustering keys a partition pruning.
Statistiky a cardinality estimation
Optimalizér vybírá plán podle statistik o distribuci hodnot (histogramy, NDV, MCV). Zastaralé nebo nepřesné statistiky vedou ke špatnému plánu — Nested Loop místo Hash Join, full scan místo index seek. Pravidelně spouštět ANALYZE/UPDATE STATISTICS, u velkých tabulek používat sampling, u datově zkosených sloupců extended/multi-column statistics.
Joins — Hash, Nested Loop, Merge
Nested Loop je optimální pro malé výsledky a indexovaný vnitřní side. Hash Join pro velké datasety bez indexu — staví hash tabulku v paměti. Merge Join pro již seřazené vstupy. Špatná volba joinu (typicky Nested Loop nad milionovou tabulkou) je #1 příčina pomalých dotazů. Často řešitelné lepším indexem, statistikami nebo query hintem.
Partitioning a clustering
Partitioning rozdělí tabulku podle klíče (datum, region) na fyzicky oddělené segmenty — dotaz s filtrem na klíč čte jen relevantní partitions (partition pruning). Clustering (Snowflake, BigQuery) drží řádky se stejnou hodnotou klíče vedle sebe pro efektivní micro-partition pruning. Pro velké faktové tabulky obvykle 10–100× zrychlení a úspora cloud creditů.
Materialized views a result cache
Materialized view ukládá výsledek dotazu fyzicky a refreshuje se podle politiky (immediate, on-commit, scheduled). Vhodné pro opakované náročné agregace v BI. Result cache (Snowflake, BigQuery) automaticky vrací výsledek deterministického dotazu zdarma. dbt incremental modely a Snowflake dynamic tables jsou moderní alternativy.
OLTP vs OLAP optimalizace
OLTP databáze (PostgreSQL, MySQL, SQL Server) optimalizují krátké transakce — primárním nástrojem jsou indexy, locking, connection pooling, normalizace. OLAP/MPP enginy (Snowflake, BigQuery, Redshift, ClickHouse) optimalizují skenování miliard řádků — důležitý je columnar storage, partition pruning, clustering, warehouse sizing a denormalizace do star/snowflake schématu.
Snowflake query optimization
Ve Snowflake snižte náklady pomocí: vhodné warehouse velikosti (auto-suspend, auto-resume), clustering keys na velkých tabulkách, result cache, materialized views, query tagging pro chargeback, SEARCH OPTIMIZATION pro point lookups. Query Profile ukáže micro-partitions scanned, spilling do remote disku a bottleneck operátory.
BigQuery a slot optimization
BigQuery účtuje za zpracovaná data (on-demand) nebo slot-hours (flat-rate). Optimalizace: vyhnout se SELECT *, partitioning by date, clustering podle filtru, materialized views, BI Engine pro Looker, INFORMATION_SCHEMA.JOBS pro audit. Reservation a slot autoscaling umožňují předvídatelné náklady při proměnlivé zátěži.
Časté antipatterny
Typické chyby: SELECT * (zbytečný I/O), funkce nad indexovaným sloupcem (WHERE UPPER(email) = ...), implicitní type cast, OR místo UNION ALL, korelované poddotazy místo joinu, příliš mnoho indexů (zpomalí INSERT/UPDATE), N+1 dotazy z aplikace. Většinu odhalí slow query log + EXPLAIN audit.
Monitoring a continuous tuning
Pro udržitelný výkon: pg_stat_statements / Query Store / Snowflake QUERY_HISTORY, alerting na regrese p95 latence, automatický EXPLAIN diff v CI pro kritické dotazy, observability tools (Datadog, New Relic, Grafana). Pravidelný cost review a top-N pomalých dotazů. Tuning není jednorázový — datový objem a workload se mění.