Museli jste někdy optimalizovat dotazy?

Ano, to jsem zažil. Optimalizace dotazů je důležitou součástí vývoje vysoce výkonných aplikací.

Moje zkušenosti zahrnují:

• Analýza plánu provádění dotazu (EXPLAIN): Použití EXPLAIN k pochopení, jak databáze provádí dotaz, jaké indexy jsou používány a kde vznikají úzká místa.
• Vytváření a optimalizace indexů: Přidání vhodných indexů na často používané sloupce a tvorba složených indexů pro urychlení filtrování, řazení a spojení. Odstranění nepoužívaných nebo duplicitních indexů.
• Přepis neefektivních dotazů:
  • Nahrazení SELECT * výběrem konkrétních sloupců.
  • Použití vhodnějších typů spojení (JOIN) místo poddotazů nebo vnořených smyček na úrovni aplikace.
  • Zjednodušení podmínek WHERE.
  • Vyhýbání se funkcím v podmínkách WHERE na indexovaných sloupcích.
  • Optimalizace GROUP BY a ORDER BY.
• Normalizace/denormalizace: Použití normalizace ke snížení redundance nebo v některých případech denormalizace ke zrychlení čtení dat pomocí duplikace nebo vytváření agregovaných sloupců (s opatrností).
• Cacheování výsledků dotazů: Implementace cache na úrovni aplikace nebo použití mechanismů cache databáze (například Redis, Memcached) ke snížení zátěže databáze při čtení často dotazovaných a málo měněných dat.
• Omezení výběru dat: Použití LIMIT pro stránkování nebo výběr pouze potřebného počtu záznamů.
• Monitoring a profilování: Použití monitorovacích nástrojů (například Percona Monitoring and Management, phpMyAdmin s povoleným Slow Query Log) k identifikaci pomalých dotazů.

Příklad analýzy s EXPLAIN:

// Příklad pomalého dotazu bez indexu na sloupci status
SELECT * FROM orders WHERE status = 'pending' AND created_at < CURDATE();

// Analýza plánu
EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND created_at < CURDATE();
// Může ukázat úplné skenování tabulky (ALL) nebo nevyužití vhodného indexu.

// Přidání složeného indexu na oba sloupce
CREATE INDEX idx_status_created_at ON orders (status, created_at);

// Opětovná analýza po vytvoření indexu
EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND created_at < CURDATE();
// Očekává se, že typ (type) se změní na ref nebo range, a Extra bude obsahovat "Using where;"