Den dårlige nyhed:der er GUI-værktøjer til at hjælpe med dette, men det er et dygtigt og vidtfavnende job. Så de dækker ikke alt, det er sandsynligt, at du bliver nødt til at bruge kommandolinje-ting/sql-sætninger osv. for at hjælpe. Jeg har kun rigtig brugt kommandolinjeværktøjerne. Jeg vil give lidt af et overblik over ting jeg kender/har brugt:
Først skal du have et godt databasedesign. Hvis designet er dårligt, kan du kun komme så langt. Dette inkluderer normalisering samt brug af passende typer til felter. Jeg lader dette punkt stå her, da jeg synes, det er lidt af en side, og ikke hvad du leder efter.
Sørg for, at MySQL Query Cache er sat op og fungerer, og giv den lidt mere RAM, hvis du kan, og sørg for, at dine vigtige forespørgsler ikke gør noget, der forhindrer mysql i at cache dem. For eksempel, ved at bruge funktionen NOW() i forespørgsler gør dette - af indlysende årsager - NU ændres hvert sekund! Du kan i stedet sætte et tidsstempel ind i sql'en, og bruge tiden til nærmeste minut/time/dag (den største periode, du kan slippe af sted med) for at tillade mysql at få nogle cachingfordele.
For at begynde at optimere ting:At stikke "EXPLAIN" foran select er måden at se, hvordan en forespørgsel udføres og identificere, hvordan den kan forbedres. Lær at fortolke outputtet:http://dev.mysql .com/doc/refman/5.0/da/using-explain.html Du vil ofte være i stand til at tilføje nye indekser/føje kolonner til eksisterende for at forbedre tingene. Men du vil også støde på tidspunkter, hvor forespørgsler skal omstruktureres.
At starte med at forbedre ydeevnen med MySQL (forudsat at du ikke allerede ved, hvad problemforespørgslen er), er at tjekke den langsomme forespørgselslog - den logger til en fil, alle forespørgsler, der tager længere tid end x sekunder.
Oversigt, inklusive config for, hvis det ikke logger dette allerede, er her:http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html - Jeg har også fundet ud af, at det at sætte long_query_time til 0 for en dag eller deromkring, så alle forespørgsler bliver logget her med tiden, er en nyttig måde at få en idé om, præcis hvor ydeevnen er på vej hen. Men jeg ville ikke tage dertil med det samme! Og lad det ikke blive siddende, logfilerne kan blive massive.
Når du har et par dages logning, har jeg fundet mysqlsla (mysql slow log analysator) herfra:http://hackmysql.com/mysqlsla er et godt værktøj.
Den kan mere end bare langsom forespørgselsloganalyse - læs manualen. Men for at forklare, hvad det gør for langsomme logfiler:den langsomme forespørgselslog kan indeholde en masse data, så det kan være svært at finde ud af, hvilke forespørgsler der er de dyreste samlet set - f.eks.:tag hensyn til, hvor mange gange de kører, og hvornår to forespørgsler er faktisk det samme med et andet id i en where-klausul.
MySQL sla gør alt dette for dig. Den kører gennem loggen og kan gruppere forespørgsler, der er de samme/har forskellige værdier i where-sætningerne. Den præsenterer dig derefter (som standard) de 10 bedste forespørgsler i form af samlet eksekveringstid - som ofte har nogle overraskelser, men som regel er det mest produktive udgangspunkt - tag den dyreste forespørgsel og brug EXPLAIN på den og se om du kan forbedre det.
Nogle forespørgsler tager lang tid og kan ikke nemt forbedres. Kan du i dette tilfælde få dataene på en anden måde eller i det mindste cache dem i stedet for? Du kan endda opleve, at det er nødvendigt at ændre DB-skemaet. På samme måde kan nogle forespørgsler være øverst i mysqlsla-outputtet, fordi du kører dem meget (især sandt, hvis long_query_time er sat til 0), selvom de kører ret hurtigt. Måske på tide at tilføje caching til din app?
http://www.maatkit.org/ ser også lovende ud - har aldrig brugt det, men mk-query-profiler-værktøjet burde være nyttigt til yderligere at undersøge, hvorfor forespørgsler går langsommere.
En helt separat ting at se også på:"status"-siden i PHPMYADMIN (eller du kan køre alle forespørgsler for at generere denne info ....) - den fremhæver ting, den mener kan være dårlige med rødt, og kan hjælpe dig se, hvor du kan få fordel af at allokere systemressourcer. Jeg ved ikke så meget om dette - min tilgang har altid været, at hvis noget er rødt og ser dårligt ud, skal jeg læse op om det og beslutte, om det er vigtigt, og om jeg skal gøre noget (betyder normalt, at der tildeles flere ressourcer til MySQL ved at ændre konfiguration).
For nylig har jeg fundet ud af, at det også kan være nyttigt at køre SHOW PROCESSLIST på en server, der lider. Selvom det kun giver dig live (nå, et live øjebliksbillede) info, kan det hjælpe dig med at få en fornemmelse af, hvad der foregår på et givet tidspunkt, især hvis du opdaterer et par gange og observerer ændringerne. Jeg har for nylig set en server, der bruger alle tilgængelige mysql-forbindelser til at køre en identisk forespørgsel ved hjælp af denne metode. Sikker på, det ville have været i den langsomme forespørgselslog, men dette som en virkelig hurtig og indlysende måde at se, hvad der var op.