Přiznám se, že napsat tenhle článek bylo pro mě jednou z nejtěžších věcí v celém seriálu o MySQL. Jde totiž o téma, které se dá pojmout velmi různě - o nastavení serveru. Člověk by mohl sklouznout k mnoha špatným metodám, jak o něčem takovém napsat povídání. Mohl bych například podat suchopárný, nezáživný, vyčerpávající a nezapamatovatelný seznam konfiguračních voleb; mohl bych opsat originální dokumentaci nebo bych se mohl vášnivě rozhovořit o tom, jak to dělám na "svých" instalacích MySQL a proč právě to je "ta nejlepší" cesta.

Pokusil jsem se to všechno neudělat; a mám k tomu moc dobrý důvod. Nastavování serveru totiž není jako nastavování pračky. Databázový server může být používán mnoha způsoby a proto také musí být odlišně vyladěn. Proč? Není to snad tak, že server MySQL slouží jen jako úložiště dat? Ano a ne. Uvědomme si, že jeden a tentýž databázový server může být nastaven různě - a přece pokaždé "správně". Co tedy spolurozhoduje o tom, jak nastavit (kolega by řekl "vytunit") MySQL? Když se nad tím zamyslíte, mohou to být například následující činitele (přičemž mnoho dalších jsem pro jednoduchost vynechal):

• Na jakém hardware server poběží. Paměť, disky a procesor budou hrát klíčovou roli
  
• Zda musíme mít zajištěnou nepřetržitou dostupnost nebo se smíme smířit s občasnými výpadky (třeba u testovacích serverů)
  
• Jakým způsobem se s daty pracuje. Často se vkládá? Často se používá SELECT?
  
• Kolik uživatelů bude k serveru připojeno. Kolik z nich bude chtít pracovat zároveň.
• Jaký je objem dat. Kolik máme databází, kolik tabulek v nich a jak často se ty které tabulky používají.
• Jaké máme typy tabulek.
• Jaké máme indexy a jak často a hojně se využívají.
  
• Zda se používají transakce.

Jak uvídíme, vzít to všechno v úvahu je silně nad rámec seriálu. Proto jsem se rozhodl popsat celé nastavení na několika málo příkladech a doufat, že vnímavý čtenář si odvodí odpovídající postupy i pro další proměnné a volby.

Nastavujeme MySQL

Není to zase tak složité. Pokud chcete v MySQL něco nastavit, potřebujete vlastně "jen":

• Vědět, co hledáte
• Vědět, kde a jak se to mění
• Vědět, co to způsobí a vědět jak to ověřit
  
• Vědět, jak se vrátit k původní konfiguraci pokud "to" nebude fungovat

Popíšu celé na příkladu. Zjistíme třeba, že řazení záznamů nám trvá neúměrně dlouho a že by bylo třeba si trochu pohrát s nastavením výkonu pro příkaz ORDER BY. Pravda, příklad je trošku vyumělkovaný, ale záměrně jsem zvolil něco jednoduchého.

Vědět co hledáme

Neexistuje obecný návod; leda byste si každou z voleb pamatovali. Pokud budete chtít optimalizovat řazení dat, pravděpodobně se podíváte do manuálu a zjistíte, že výkon řazení může ovlivnit proměnná sort_buffer_size. Udává velikost bufferu, který si alokuje každé vlákno vykonávající řazení dat. S hodnotou si můžeme samozřejmě pohrát; přičemž je třeba vzít v úvahu, kolik paměti vlastně máme celkem pro server k dispozici a kolik vláken nám (odhadem) bude zároveň potřebovat řadit data.

Pozn.: Údaj "kolik paměti máme pro server" je ošidný sám o sobě. Nezapomeňte, že v reálném světě nám může na jednom stroji kromě MySQL běžet ještě řada služeb či programů a ty potřebují další paměť. Takže to berte opravdu jen jako příklad.

Vědět, kde a jak se to mění

Začněme tím, že si ukážeme, jak vlastně zjistit aktuální hodnotu konfiguračních voleb. To je jednoduché. Stačí se připojit k databázi a zadat příkaz:

Cože? Že se v nich nemůžete vyznat? Jenom jsem Vás zkoušel. Moje instalace MySQL 5 obsahuje 209 konfiguračních proměnných, takže v nich se opravdu špatně hledá. Mnohem lepší je

A hned vidíte, jak na tom jste. Když už jsme u příkazu SHOW VARIABLES, tak bych měl asi upřesnit, že neobsahuje jen měnitelné, konfigurovatelné hodnoty. Obsahuje rovněž například informace o verzi serveru, kterou pochopitelně přepsat nemůžete. Změnit hodnotu proměnné - když to jde - můžete příkazem SET, nějak takto:

Zapamatujte si, že pokud to uděláte, bude nová hodnota platit ihned, ovšem pouze do ukončení aktuálního spojení a pouze pro toto spojení. Jestliže vy nebo někdo jiný otevřete jiné spojení, bude v novém spojení opět původní hodnota proměnné. Což je hezké, ale jak změnit hodnotu pro všechna připojení? Použitím klíčového slova GLOBAL, nějak takto:

V tomto případě bude nová hodnota platit pro všechna od této chvíle vytvořená nová spojení až do restartu serveru. Z toho ovšem vyplývá, že pro spojení, které proměnnou nastavilo nová hodnota neplatí (pozor na to).

Pokud nám ani to nestačí a potřebujete proměnnou nastavit pro celý server a po každém spuštění, je třeba zabrousit do konfiguračního souboru. Ten bude umístěn typicky v /etc/my.cnf (nebo jinde podle distribuce) a bude mít formát jako ... ini soubor ve Windows. Takže změnu sort_buffer_size provedeme editací příslušné sekce:

Pozor, konfigurační hodnoty jsou načítány při startu serveru, tudíž při jejich změně bude nutné MySQL restartovat. A ještě informace pro opravdové znalce: hodnoty konfiguračních voleb můžete povětšinou zadat při startu serveru rovněž jako přepínače do příkazového řádku. Načítání voleb ze souboru mi však přijde mnohem přehlednější.

Jak to ověřit

Docela problém, protože většina voleb má na výkon relativně malý dopad. Dopad změny velikosti proměnné sort_buffer_size bychom mohli ověřit nějak takto:

Čas potřebný ke zpracování výsledků by neměl být stejný, zejména pokud provedete více měření na reálném provozu.

Jak se vrátit k původní konfiguraci

Jak jste asi pochopili, občas bude mít význam vyzkoušet si změnu serverové proměnné pouze pro dané spojení. O návrat do původního stavu se pak vlastně nemusíme starat, protože po ukončení spojení se specifické nastavení ztratí. Jestliže nastavíte proměnnou pomocí set global, její hodnota se obnoví po restartu serveru na původní hodnoty. Pokud se chcete zabývat změnami konfiguračních souborů, je jasné, že bude třeba si je nejprve zálohovat. Pokud se něco pokazí, lze se vrátit k záloze. A ještě něco: do konfiguračních souborů lze psát poznámky. Využijte toho, napište si třeba datum a čas změny, původní hodnotu proměnné nebo proč jste tu kterou volbu měnili. Uvidíte, že to není zbytečná práce.

Protože sort_buffer_size byla použita opravdu jen jako příklad, podíváme se v dalším díle na to, které serverové proměnné mohou ovlivnit naši konfiguraci opravdu podstatným způsobem a také si řekneme, jak zjišťovat stavové informace o právě běžící instanci serveru. Takže se máte na co těšit.