Лошата новина:има GUI инструменти, които да помогнат с това, но това е квалифицирана и широка работа. Така че те не покриват всичко, вероятно ще трябва да използвате неща от командния ред/sql оператори и т.н., за да помогнете. Наистина използвах само инструментите на командния ред. Ще дам кратък преглед на нещата, които знам/използвал съм:
Първо, имате нужда от добър дизайн на база данни. Ако дизайнът е лош, можете да стигнете само дотук. Това включва нормализиране, както и използване на подходящи типове за полета. Ще оставя тази точка тук, тъй като мисля, че е малко настрана, а не това, което търсите.
Уверете се, че MySQL Query Cache е настроен и работи и му дайте малко повече RAM, ако можете, и се уверете, че вашите важни заявки не правят нищо, което пречи на mysql да ги кешира. Например, използването на функцията NOW() в заявките прави това - по очевидни причини - СЕГА се променя всяка секунда! Вместо това можете да поставите клеймо за време в sql и да използвате времето до най-близката минута/час/ден (най-големият период, с който можете да се разминете), за да позволите на mysql да получи някаква полза от кеширането.
За да започнете да оптимизирате нещата:Залепването на "EXPLAIN" пред select е начинът да видите как се изпълнява заявката и да определите как да я подобрите. Научете се да интерпретирате изхода:http://dev.mysql .com/doc/refman/5.0/en/using-explain.html Често ще можете да добавяте нови индекси/добавяйте колони към съществуващите, за да подобрите нещата. Но също така ще срещнете моменти, когато заявките трябва да бъдат преструктурирани.
Да започнете да подобрявате производителността с MySQL (ако приемем, че все още не знаете каква е проблемната заявка) е да проверите бавния дневник на заявките – той записва във файл, всички заявки отнемат повече от x секунди.
Общ преглед, включително конфигурация за, ако вече не регистрира това, е тук:http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html - Открих също, че задаване на long_query_time на 0 за ден или нещо, така че всички заявки да се регистрират тук с отнето време, е полезен начин да получите представа къде точно върви изпълнението. Но не бих отишла там веднага! И не го оставяйте включен, трупите могат да станат масивни.
След като имате няколко дни за регистриране, открих mysqlsla (mysql бавен лог анализатор) от тук:http://hackmysql.com/mysqlsla е добър инструмент.
Той може да направи повече от просто бавен анализ на дневника на заявките - прочетете ръководството. Но за да обясня какво прави за бавни регистрационни файлове:бавният регистър на заявките може да съдържа много данни, така че може да е трудно да се разбере кои заявки са най-скъпите като цяло - напр.:вземете предвид колко пъти се изпълняват и кога две заявки всъщност са едни и същи с различен идентификатор в клауза where.
MySQL sla прави всичко това вместо вас. Той преминава през дневника и може да групира заявки, които са еднакви/има различни стойности в клаузите where. След това ви представя (по подразбиране) първите 10 заявки по отношение на общото време за изпълнение - което често има някои изненади, но обикновено е най-продуктивната отправна точка - вземете най-скъпата заявка и използвайте EXPLAIN върху нея и вижте дали можете да подобрите го.
Някои заявки отнемат много време и не могат лесно да бъдат подобрени. В този случай можете ли да получите данните по друг начин или поне да ги кеширате? Може дори да откриете, че е необходима промяна на DB схемата. По същия начин някои заявки може да са в горната част на изхода на mysqlsla, защото ги изпълнявате много (особено вярно, ако long_query_time е настроен на 0), дори и да се изпълняват доста бързо. Може би е време да добавите малко кеширане към приложението си?
http://www.maatkit.org/ също изглежда обещаващо - никога не съм го използвал, но инструментът mk-query-profiler би трябвало да е полезен за по-нататъшно разглеждане защо заявките се забавят.
Съвсем отделно нещо, което също трябва да разгледате:страницата "състояние" в PHPMYADMIN (или можете да стартирате всички заявки, за да генерирате тази информация ....) - тя подчертава нещата, които смята, че може да са лоши в червено и може да ви помогне вижте къде може да се възползвате от разпределянето на системни ресурси. Не знам толкова много по въпроса - моят подход винаги е бил, че ако нещо е червено и изглежда зле, да отида и да прочета за него и да реша дали е важно и дали трябва да направя нещо (обикновено означава да разпределя повече ресурси за MySQL чрез промяна на конфигурацията).
Наскоро открих, че стартирането на SHOW PROCESSLIST може да бъде полезно и на сървър, който страда. Въпреки че ви дава само информация на живо (е, моментна снимка на живо), може да ви помогне да усетите какво се случва в даден момент, особено ако опресните няколко пъти и наблюдавате промените. Наскоро забелязах сървър, използващ всяка налична mysql връзка за изпълнение на идентична заявка, използвайки този метод. Разбира се, това би било в бавния регистър на заявките, но това е наистина бърз и очевиден начин да видите какво става.
