Co nefunguje v MySQL a jak to obejít

U sloupce typu date nelze nastavit výchozí čas na aktuální

Problém: Hodnota DEFAULT CURRENT_TIMESTAMP z historických důvodů funguje pouze u sloupce typu timestamp a navíc ji lze použít jen u jednoho takovéhoto sloupce v tabulce.

Řešení: Častý požadavek na existenci dvou sloupců vytvoreno a zmeneno se tedy řeší poněkud krkolomně. Dá se zajistit vytvořením BEFORE INSERT triggeru:

CREATE TRIGGER tabulka_bi BEFORE INSERT ON tabulka FOR EACH ROW
SET NEW.vytvoreno = NOW()

Sloupec zmeneno může být klasický timestamp.

Sestupné indexy

Problém: MySQL při definici indexů ignoruje požadavek na sestupné třídění položek – (skupina DESC, poradi) vytvoří stejný index jako (skupina, poradi).

Řešení: MySQL dokáže takovýto index použít i pro sestupné třídění, důležité ale je, aby pořadí všech částí indexu bylo při třídění stejné: ORDER BY skupina DESC, poradi DESC index využije, dotaz ORDER BY skupina DESC, poradi ne. Pokud to nedokážeme zaručit, můžeme do tabulky vložit opačnou hodnotu sloupce a řadit podle něj, obvykle to ale potřeba není.

Indexy nad výsledkem funkce

Problém: MySQL na rozdíl třeba od PostgreSQL nedovoluje vytvářet indexy nad výsledkem funkce. Pokud na sloupec v dotazu aplikujeme nějakou funkci, tak se index až na výjimky nepoužije.

Řešení: Při porovnávání je tedy vhodné indexované sloupce uvádět samotné:

-- index se nepoužije
SELECT * FROM tabulka WHERE zmeneno + INTERVAL 1 DAY >= NOW();

-- použije se index nad sloupcem (zmeneno)
SELECT * FROM tabulka WHERE zmeneno >= NOW() - INTERVAL 1 DAY;

Materializované pohledy

Problém: Pohledy se v MySQL vyhodnocují při každém dotazu znovu. Na rozdíl od jiných databázových serverů nedokáže MySQL vytvořit tzv. materializovaný pohled, který by data fyzicky ukládal (a při změně aktualizoval) a nad kterým by třeba šly definovat i indexy.

Řešení: Vyřešit se to obvykle dá doplněním dopočítávaných sloupců a jejich automatickou aktualizací pomocí triggerů, dá to ale dost práce.

Trigger nemůže měnit stejnou tabulku

Problém: Trigger nemůže měnit data ve stejné tabulce, pro kterou je definován.

Řešení: Žádný work-around neznám, ale pokud nám stačí upravit modifikovaný záznam, lze to udělat změnou hodnot v „tabulce“ NEW.

Stejné omezení platí i pro poddotazy při modifikaci záznamu – ty se také nemohou dotazovat do stejné tabulky. Takový příkaz je nutné rozdělit do dvou – nejprve získat data a v druhém kroku provést aktualizaci.

Triggery se nespustí při kaskádovém mazání

Problém: Pokud definujeme cizí klíč s příznakem ON DELETE CASCADE a v tabulce je definovaný trigger pro smazání, tak se tento trigger nespustí, pokud se záznam smaže v důsledku kaskády.

Řešení: Řešení je pro tabulky s takovýmto triggerem nepoužívat kaskádové mazání a záznamy mazat ručně. Často ale trigger pouze mění záznam v rodičovské tabulce, kdy nám jeho nespuštění nemusí vadit.

Příkazy ukončující transakci

Problém: Všechny příkazy pracující se strukturou tabulek vyvolají implicitní COMMIT právě probíhající transakce. Platí to i pro další příkazy, např. ty pro práci s uživateli a donedávna třeba i pro příkaz LOAD DATA.

Řešení: V transakcích je tedy vhodné používat jen příkazy manipulující s daty.

Omezující podmínky

Problém: MySQL ignoruje omezující podmínky definované klauzulí CHECK při vytváření tabulky.

Řešení: Obejít se to dá triggerem, který v případě nesplnění podmínky vyvolá chybu:

CREATE TRIGGER uzivatel_bi BEFORE INSERT ON uzivatel FOR EACH ROW
IF CHAR_LENGTH(NEW.login) < 3 THEN
	DO `Login musí mít alespoň tři znaky.`;
END IF

Stejný trigger bychom samozřejmě museli definovat i pro změnu záznamu.

Všimněte si také krkolomného způsobu vyvolání chyby, který navíc MySQL obalí hláškou, že sloupec daného jména neexistuje. V MySQL totiž neexistuje příkaz SIGNAL, který by se dal pro vyvolání chyby použít.

Závěr

MySQL je stále mladý databázový server a otázkou je, jestli budou uvedené nedostatky v blízké budoucnosti odstraněny. Lepší je proto o nich vědět a naučit se s nimi žít.

Pokud jste narazili na další gotchas, tak s nimi čtenáře můžete seznámit v diskusi.