Názory k článku
Zvyšujeme výkon MySQL změnou konfigurace

„naváže další díl, který pojedná o horizontálním škálování, a poslední díl pak o replikaci a možnostech jejího využití při vertikálním škálování“
Buď si autor plete vertikalni vs horizontální škálování, nebo to bude hodně zajímavé :)

Samozřejmě jedná se o záměnu těchto výrazů, má býti:
„V příštích dílech se podíváme na možnosti vertikálního škálování a také na replikaci a možnosti jejího využití při horizontálním škálování výkonu.“
Má omluva.

O cem muze byt clanek o vertialnim skalovani? Proste jen potunime server po fyzicke strance a je to. Clanek na jednu vetu :-)

… anebo se autor přepsal! :) Opraveno, díky za upozornění.

Inac na tuning mysql posluzi celkom sikovny skript:
http://mysqltuner.pl/mysqltuner.pl

Některé také přidám:
mysqlreport: http://hackmysql.com/mysqlreport
mysqlprimer: http://www.day32.com/MySQL/

Kromě několika překlepů je článek podle mě poměrně zdařilý. Možná bych alespoň nějaký čas věnoval specifikům InnoDB (obzvlášť primárnímu klíči, podle kterého se data organizují a který se přímo zapisuje do listů ostatních indexů, takže jeho volba má zásadní důležitost). No a pak by taky neškodilo lépe vysvětlit, jak funguje query cache (že jakákoliv změna tabulky smaže cache všech dotazů, které tabulku používají, nejen dotčených záznamů).
Rád bych se nicméně ohradil proti dvěma výrokům:
1. „tabulky typu MyISAM jsou daleko výkonnější“ – to zásadně záleží na charakteru provozu. V jednouživatelském režimu to obvykle platí, ale ve víceuživatelském (který je zcela typický pro webové aplikace) to může být přesně naopak. Obzvlášť kombinace UPDATE a SELECT (i nesouvisejících záznamů v jedné tabulce) může být pro MyISAM smrtelná.
2. U query cache „čím větší je počet paralelně přistupujících klientů k dané databázi“ – jakou souvislost s query cache má to, jestli klienti přistupují paralelně nebo sériově? Pokud vím, tak žádnou.

Bylo by užitečné trochu více v článku zdůraznit Query cache. Přijde mi, že převládá názor zapnutí query cache = zvýšení výkonu. Čím častější aktualizace a čím unikátnější dotazy tím méně se cache vyplatí. Nemá smysl cachovat select, který se provádí v průměru jednou za minutu, když podkladová tabulka se mění každých 10 vteřin.
>Efektivitu cache lze měřit pomocí stavových proměnných, které zobrazíme například položením dotazu SHOW STATUS LIKE ‚Qcache%‘.
Podle mě je to téměř k ničemu, často jsou v aplikaci dotazy na malé pomocné tabulky, které jsou rychlé a tuhle statistiku úplně rozhodí. Je lepší se vždy zamýšlet opravdu nad tím kolikrát se po update, insert nebo delete provede select – tedy 2×, 1000×? Není univerzální odpověď kdy cache a no a kdy ne.
I pokud se tabulka nemění často může query cache dělat problémy – pokud na tabulku míří velká spousta neopakujících se dotazů. Taková změna tabulky po 1 000 000 unikátních dotazů, může trvat relativně dlouho (kromě změny tabulky se bude měnit i cache).

Samozřejmě, že článek nemohl obsáhnout všechny možnosti a nastavení, už takto jsem se musel značně omezovat, abych se vešel do rozumného maxima délky článku. Od toho jsou tu dobré ty diskuze, kde je možné některé důležité věci zdůraznit.
Mno už aby vyšla verze MySQL 5.5, jež slibuje velmi pěkné navýšení výkonu zejmnéma pro tabulky InnoDB a také semisynchronní replikace. Doufám, že se vývojářům povede vydat GA verzi o prázdninách.

+/- souhlas, ale na druhou stranu nad MySQL existuje řada fajn aplikací, takže se hodí umět poladit i MySQL databázi – ne všechno můžeš zmigrovat do PostgreSQL (i když ta aplikace o sobě tvrdí, že to jde, tak se nakonec může ukázat, že jí nikdo s jinou databází netestoval a odladěná je jen pro MySQL).

Já jsem před rokem srovnal funkce MySQL a PostgreSQL: http://php.vrana.cz/srovnani-funkci-mysql-a-postgresql.php
Je to čistě srovnání funkcí, nezohledňoval jsem výkonnost, konfigurovatelnost, využitelnost (rozšířenost) a tak dále.

Na googlu se dá najít celkme dost článků včetně benchmarků
http://www.google.cz/search?hl=&q=mysql+vs+postgresql+performance&sourceid=navclient-ff&rlz=1B5GGGL_csCZ301CZ303&ie=UTF-8&aq=3&oq=mysql+vs+p
celkem pěkné porovnání včetně dalších odkazů
http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

v cem je rozdil? reknu to ze sveho pohledu. DB pouzivam temer vyhradne pro analyticke ucely.. tzn mam v nich ulozeny data a vytvarim nad nima reporty, slozite selecty, analyzy … Mysql stale nepodporuje celou radu sql prikazu, ktere jsou v tzv SQL standardu a musi se to slozite obchazet .. Je to takovy voser, ze by jeden skakal z okna. Bohuzel nekteri klienti maji data v tomto systemu :-( Pokud to alespon trochu jde, delam import do rozumejsich systemu jako je postgre, oracle apod …
MySQL podle me nema zadne opodstatneni. Dnes uz neni ani rychla, ani „light“ … vsechny drivejsi vyhody konkurence dohnala, tak proc pouzivat nedodelek?

Všechny? Nezpochybňuju, že mysql je děs, ale která free databáze nabízí dobře vyřešenou replikaci?

A na tohle jste prisel kde? Podle me je to prave naopak...