Het slechte nieuws:er zijn GUI-tools om je hierbij te helpen, maar het is een bekwame en brede taak. Ze dekken dus niet alles, het is waarschijnlijk dat je dingen op de commandoregel/sql-statements enz. moet gebruiken om te helpen. Ik heb alleen echt de opdrachtregelprogramma's gebruikt. Ik zal een beetje een overzicht geven van dingen die ik weet/heb gebruikt:
Ten eerste heb je een goed database-ontwerp nodig. Als het ontwerp slecht is, kun je alleen zo ver komen. Dit omvat normalisatie, evenals het gebruik van geschikte typen voor velden. Ik laat dit punt hier, omdat ik denk dat het een beetje terzijde is, en niet wat je zoekt.
Zorg ervoor dat de MySQL-querycache is ingesteld en werkt en geef het een beetje meer RAM als je kunt, en zorg ervoor dat je belangrijke vragen niets doen dat mysql-cache verhindert. Als u bijvoorbeeld de functie NU() in query's gebruikt, verandert dit - om voor de hand liggende redenen - NU elke seconde! Je kunt in plaats daarvan een tijdstempel in de sql plaatsen en de tijd gebruiken tot op de minuut/uur/dag (de grootste periode waarmee je weg kunt komen) om mysql wat caching-voordeel te geven.
Om te beginnen met het optimaliseren van dingen:door "EXPLAIN" voor select te plakken, is DE manier om te zien hoe een query wordt uitgevoerd en te bepalen hoe deze kan worden verbeterd. Leer de uitvoer te interpreteren:http://dev.mysql .com/doc/refman/5.0/en/using-explain.html Je kunt vaak nieuwe indexen toevoegen/kolommen toevoegen aan bestaande om dingen te verbeteren. Maar je zult ook momenten tegenkomen dat zoekopdrachten moeten worden geherstructureerd.
Beginnen met het verbeteren van de prestaties met MySQL (ervan uitgaande dat u niet al weet wat de probleemquery is) is om het trage querylogboek te controleren - het logt in een bestand dat alle query's langer dan x seconden duren.
Overzicht, inclusief configuratie voor als het dit nog niet registreert, is hier:http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html - Ik heb ook ontdekt dat het een handige manier is om een idee te krijgen van waar de prestatie precies naartoe gaat als je long_query_time een dag of zo op 0 zet, zodat alle zoekopdrachten hier worden gelogd met de benodigde tijd. Maar ik zou er niet meteen heen gaan! En laat het niet aanstaan, de logs kunnen enorm worden.
Zodra je een paar dagen aan loggen hebt, heb ik mysqlsla (mysql slow log-analyser) hier gevonden:http://hackmysql.com/mysqlsla is een goed hulpmiddel.
Het kan meer doen dan alleen een langzame analyse van het querylogboek - lees de handleiding. Maar om uit te leggen wat het doet voor langzame logboeken:het logboek voor langzame zoekopdrachten kan veel gegevens bevatten, dus het kan moeilijk zijn om erachter te komen welke zoekopdrachten in het algemeen het duurst zijn - bijvoorbeeld:bereken hoe vaak ze worden uitgevoerd en wanneer twee zoekopdrachten zijn eigenlijk hetzelfde met een andere id in een waar-clausule.
MySQL sla doet dit allemaal voor u. Het loopt door het logboek en kan query's groeperen die hetzelfde zijn/verschillende waarden hebben in de waar-clausules. Vervolgens presenteert het u (standaard) de top 10 van zoekopdrachten in termen van totale uitvoeringstijd - wat vaak enkele verrassingen heeft, maar meestal het meest productieve startpunt is - neem de duurste zoekopdracht en gebruik EXPLAIN erop en kijk of u het kunt verbeteren het.
Sommige zoekopdrachten duren lang en kunnen niet eenvoudig worden verbeterd. Kunt u in dit geval de gegevens op een andere manier ophalen of in plaats daarvan in de cache opslaan? Mogelijk vindt u zelfs dat het wijzigen van het DB-schema vereist is. Evenzo kunnen sommige query's bovenaan de mysqlla-uitvoer staan omdat u ze veel uitvoert (vooral waar als long_query_time is ingesteld op 0), zelfs als ze behoorlijk snel worden uitgevoerd. Misschien tijd om wat caching aan je app toe te voegen?
http://www.maatkit.org/ ziet er ook veelbelovend uit - nooit gebruikt, maar de mk-query-profiler-tool zou nuttig moeten zijn om verder te onderzoeken waarom zoekopdrachten traag zijn.
Een heel ander ding om naar te kijken:de "status" -pagina in PHPMYADMIN (of je kunt alle zoekopdrachten uitvoeren om deze informatie te genereren ....) - het markeert dingen waarvan hij denkt dat ze slecht zijn in het rood, en kan je helpen kijk waar u voordeel kunt halen uit het toewijzen van systeembronnen. Ik weet hier niet zoveel van - mijn benadering is altijd geweest dat als iets rood is en er slecht uitziet, ik erover moet gaan lezen en beslissen of het belangrijk is en of ik iets moet doen (meestal betekent het toewijzen van meer middelen aan MySQL door de configuratie te wijzigen).
Onlangs heb ik ontdekt dat het uitvoeren van SHOW PROCESSLIST ook nuttig kan zijn op een server die lijdt. Hoewel het je alleen live (nou ja, een live snapshot) informatie geeft, kan het je helpen een idee te krijgen van wat er op een bepaald moment aan de hand is, vooral als je een paar keer ververst en de veranderingen observeert. Ik heb onlangs een server gezien die elke beschikbare mysql-verbinding gebruikt om een identieke query uit te voeren met behulp van deze methode. Natuurlijk, het zou in het log met trage zoekopdrachten hebben gestaan, maar dit was een heel snelle en voor de hand liggende manier om te zien wat er aan de hand was.