Špatná zpráva:existují nástroje GUI, které s tím pomohou, ale je to kvalifikovaná a rozsáhlá práce. Takže nepokrývají vše, je pravděpodobné, že budete muset použít příkazy příkazového řádku/příkazy SQL atd. Opravdu jsem používal pouze nástroje příkazového řádku. Uvedu malý přehled věcí, které znám/použil jsem:
Nejprve potřebujete dobrý návrh databáze. Pokud je design špatný, můžete se dostat jen tak daleko. To zahrnuje normalizaci a také použití vhodných typů pro pole. Tento bod zde nechám, protože si myslím, že je to trochu stranou a ne to, o co vám jde.
Ujistěte se, že je mezipaměť dotazů MySQL nastavena a funguje, a pokud můžete, dejte jí trochu více paměti RAM a ujistěte se, že vaše důležité dotazy nedělají nic, co by bránilo jejich ukládání do mezipaměti mysql. Například pomocí funkce NOW() v dotazech se to – ze zřejmých důvodů – NOW mění každou sekundu! Místo toho můžete do sql vložit časové razítko a použít čas zaokrouhlený na nejbližší minutu/hodinu/den (největší období, které vám projde), abyste mysql umožnili získat výhodu ukládání do mezipaměti.
Chcete-li začít s optimalizací:Nalepit "EXPLAIN" před výběr je způsob, jak vidět, jak je dotaz prováděn, a identifikovat, jak jej zlepšit. Naučte se interpretovat výstup:http://dev.mysql .com/doc/refman/5.0/en/using-explain.html Často budete moci přidávat nové indexy/přidávat sloupce ke stávajícím, abyste věci vylepšili. Setkáte se ale také s případy, kdy je potřeba restrukturalizovat dotazy.
Začátkem zlepšováním výkonu s MySQL (za předpokladu, že ještě nevíte, co je problémový dotaz) je zkontrolovat protokol pomalých dotazů – zaznamenává do souboru všechny dotazy trvající déle než x sekund.
Přehled včetně konfigurace, pokud to již nezaznamenává, je zde:http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html - Také jsem zjistil, že nastavení long_query_time na 0 na jeden den nebo tak nějak, aby se zde všechny dotazy zaznamenávaly s časem, je užitečný způsob, jak získat představu o tom, kam přesně výkon směřuje. Ale hned bych tam nešel! A nenechávejte to zapnuté, polena mohou být masivní.
Jakmile budete mít několik dní protokolování, našel jsem mysqlsla (analyzátor pomalého protokolu mysql) odtud:http://hackmysql.com/mysqlsla je dobrý nástroj.
Umí víc než jen pomalou analýzu protokolu dotazů – přečtěte si manuál. Ale abych vysvětlil, co to dělá s pomalými protokoly:protokol pomalých dotazů může obsahovat spoustu dat, takže může být těžké zjistit, které dotazy jsou celkově nejdražší – např.:zohledněte, kolikrát se spouštějí a kdy dva dotazy jsou ve skutečnosti stejné s jiným id v klauzuli where.
MySQL sla to vše udělá za vás. Prochází protokolem a může seskupovat dotazy, které jsou stejné/mají různé hodnoty v klauzulích where. Poté vám (ve výchozím nastavení) představí 10 nejlepších dotazů z hlediska celkové doby provádění – což často přináší určitá překvapení, ale obvykle je to nejproduktivnější výchozí bod – vezměte nejdražší dotaz a použijte na něj EXPLAIN a zjistěte, zda se můžete zlepšit to.
Některé dotazy trvají dlouho a nelze je snadno zlepšit. Můžete v tomto případě získat data jiným způsobem nebo je alespoň místo toho uložit do mezipaměti? Můžete dokonce zjistit, že je potřeba změnit schéma DB. Podobně mohou být některé dotazy na začátku výstupu mysqlsla, protože je spouštíte hodně (zvláště to platí, pokud je long_query_time nastaveno na 0), i když běží docela rychle. Možná je čas přidat do své aplikace nějaké ukládání do mezipaměti?
http://www.maatkit.org/ také vypadá slibně – nikdy jsem ho nepoužil, ale nástroj mk-query-profiler by měl být užitečný k dalšímu zkoumání toho, proč se dotazy zpomalují.
Zcela samostatná věc, na kterou je třeba se také podívat:stránka "stav" v PHPMYADMIN (nebo můžete spustit všechny dotazy pro vygenerování těchto informací ....) - zvýrazní věci, o kterých si myslí, že by mohly být špatné, červeně a může vám pomoci podívejte se, kde můžete získat výhody z přidělení systémových prostředků. Moc se v tom nevyznám - můj přístup byl vždy takový, že když je něco červené a vypadá to špatně, jít si to přečíst a rozhodnout se, jestli je to důležité a jestli bych měl něco udělat (obvykle to znamená přidělit více zdrojů MySQL změnou konfigurace).
Nedávno jsem zjistil, že spuštění SHOW PROCESSLIST může být užitečné i na serveru, který trpí. I když vám poskytuje pouze živé (dobře, živý snímek) informace, může vám pomoci získat představu o tom, co se děje v daný čas, zvláště pokud několikrát obnovíte a pozorujete změny. Nedávno jsem si všiml serveru, který používá každé dostupné připojení mysql ke spuštění identického dotazu pomocí této metody. Jistě, bylo by to v protokolu pomalých dotazů, ale tohle je opravdu rychlý a zřejmý způsob, jak zjistit, co se děje.