Profilerstellung für MySQL-Abfragen mit phpMyAdmin

German (Deutsch) translation by Tatsiana Bochkareva (you can also view the original English article)

Ich benutze phpMyAdmin seit über einem Jahrzehnt. In meinen frühen Jahren mit dem Tool brauchte ich einfach etwas, das mir die Tabellenstruktur zeigen und mir schnell die darin enthaltenen Daten geben konnte. Mit den wachsenden Anforderungen sind auch die in phpMyAdmin enthaltenen Tools enthalten, mit denen ich auch bei der Optimierung immer wieder zu meinem primären MySQL-Tool zurückkehren kann.

Einführung und Umfang: Verwenden der vorhandenen Tools

Ich hatte das Vergnügen, mit verschiedenen Datenbanken zu arbeiten. Jeder hat seine Nachteile und jeder hat seine Stärken. Wenn ich die Wahl habe, tendiere ich dazu, zurück zu MySQL zu migrieren, obwohl ich zu billig bin, um MySQL Enterprise zu kaufen. Stattdessen mache ich mit phpMyAdmin als meinem Hauptprofilierungswerkzeug fällig. Es funktioniert gut für mich, aber ich musste ziemlich viel recherchieren, um zu verstehen, was ich beim Profilieren meiner Anwendungen sehe. Ich hoffe, das so zu vermitteln, dass ein Anfänger einen erfahrenen Profi verstehen kann.

Die Optimierung braucht Zeit. Manager, Kunden und Kollegen hören nicht gern, dass ein Projekt aufgrund von Optimierungen hinter dem Zeitplan zurückliegt. Oft beschleunigen wir die Optimierung, um diese Benchmarks zu erfüllen. Am Ende tun wir jedoch niemandem einen Gefallen. Die schönste Web-App der Welt kann ein Unternehmen erneut gründen, wenn das Laden jeder Seite 10 Sekunden dauert. Wenn wir bis zum Ende unserer Projekte auf die Optimierung warten, besteht wahrscheinlich auch viel mehr Arbeit, als wenn wir im Verlauf des Projekts überprüft hätten.

Ein paar Notizen, bevor wir uns mit Fleisch und Kartoffeln befassen. Erstens werde ich nicht auf MySQL Tuning eingehen, da es für dieses Tutorial etwas außerhalb des Anwendungsbereichs liegt. Während Tuning Optimierung ist, ist es meiner Meinung nach ein Thema für sich. Ich werde kurz auf einige Möglichkeiten zur Optimierung Ihres Servers eingehen, aber dies wird kurz sein Außerdem werde ich mich hauptsächlich mit MyISAM-Tabellen und nicht mit InnoDB-Tabellen befassen. Als Faustregel gilt: Wenn Sie viele Daten schreiben, verwenden Sie InnoDB. Wenn Sie jedoch viel häufiger SELECT verwenden, verwenden Sie MyISAM. Außerdem beschäftige ich mich nicht mit REPAIR, OPTIMIZE, CHECK und ANALYZE auf Tabellenebene, da dieses Tutorial die Abfrageoptimierung mit phpMyAdmin behandelt. Auch dies ist etwas außerhalb des Rahmens für dieses Tutorial.

Schließlich werde ich WordPress als ein Beispiel aus der Praxis betrachten. Ich möchte Ihnen zuerst sagen, dass ich kein Experte für WordPress bin, aber ich kann die generierten Abfragen mit den besten von ihnen betrachten. Soweit ich gesehen habe, ist die Datenbank mit WordPress gut indiziert, aber sobald wir anfangen, Dinge hinzuzufügen, die außerhalb dieser Hauptkerndateien liegen, sind diese Indizes möglicherweise nicht die besten für das, was wir brauchen.

"Die Optimierung braucht Zeit. Manager, Kunden und Kollegen hören nicht gern, dass ein Projekt aufgrund von der Optimierung hinter dem Zeitplan zurückliegt."

Muss ich optimieren? Schauen Sie intern

Die kurze Antwort lautet ja.

Die lange Antwort lautet: phpMyAdmin gibt uns die Möglichkeit zu sehen, ob wir unsere Abfragen optimieren müssen und wie dringend wir sie optimieren müssen. Ich würde mir vorstellen, dass Sie diesen Bildschirm mehr als einmal gesehen haben, wenn Sie phpMyAdmin verwendet haben:

Es ist der Standardstartbildschirm für phpMyAdmin. Wenn Sie nicht nach Optimierungsmöglichkeiten suchen, können Sie direkt zu Ihren Tabellen im linken Menü gehen und das Registerkartenmenü oben nie sehen. In diesem Menü, insbesondere auf den Registerkarten Status und Variablen, beginnen wir.

Beginnen wir mit dem Statusbildschirm, der vielleicht das wichtigste Tool von phpMyAdmin ist:

Das ist der obere Rand des Statusbildschirms. Es hat einige interessante Daten, aber wenn Sie die Schriftrolle noch nie unterschritten haben, haben Sie einige sehr wichtige Informationen verpasst. Der Kürze halber möchte ich zwei sehr einfache Zählerwerte betrachten, von denen ich besessen bin, den ersten aus meiner Testumgebung:

Die beiden Werte, auf die Sie besonders achten sollten, sind Handler_read_rnd und Handler_read_rnd_next. Wenn diese beiden Werte rote Zahlen haben, müssen einige Abfragen überprüft werden. Wenn MySQL SELECT ausführt, liest es die gesamte Tabelle. In einigen Fällen kann dies beabsichtigt sein. Wenn Sie einen Index für eine Tabelle platzieren, dauert das Schreiben etwas länger und der Speicherplatz etwas länger. Wenn Sie jedoch so etwas sehen:

Die Chancen stehen gut, dass das nicht beabsichtigt war. 141 Millionen Anfragen zum Lesen einer Zeile an einer festen Position und 16 Milliarden Anfragen zum Lesen der nächsten Zeile bedeuten wahrscheinlich, dass uns ein oder zwei (tausend) Indizes fehlen. Offensichtlich wächst diese Anzahl basierend auf der Anzahl der Anfragen. Je mehr eine Suchmaschine Ihre Website indiziert oder je mehr Besucher Sie haben, desto größer wird ein kleiner verpasster Index. Die vollständigen Tischscans sind der Feind, und auf diese Weise können Sie schnell erkennen, wie nahe dieser Feind an den Toren ist.

Eine weitere großartige Tabelle zur Überprüfung der Abfrageleistung befasst sich direkt mit Auswahlen und Indizes:

Diese Tabelle widmet Ihren Joins besondere Aufmerksamkeit. Eine gefährliche Kombination verwendet und indiziert keine der beiden Tabellen, da Ihre vollständigen Tabellenscans exponentiell an der Anzahl der von Ihnen verwendeten Verknüpfungen ansteigen. Je normalisierter Ihre Tabellen sind, desto mehr müssen Sie auf Ihre Indizes sowie auf die Definition der Felder achten, denen Sie beitreten.

Abhängig von einer globalen Variablen möchten Sie schließlich auch diese Variablentabelle überprüfen:

Wenn Sie Ihre langsamen Abfragen protokollieren, zeigt dieser Variablenzähler die Nummer an, die zur Beobachtung identifiziert wurde, abhängig von der Einstellung der langen Abfragezeit. Diese Variablen finden Sie auf der Registerkarte Variablen. Ein kurzer Blick in meine Testumgebung zeigt diese Einstellung(vorerst):

Diese beiden Registerkarten enthalten einige weitere Informationen, von denen einige für die Optimierung Ihres MySQL-Servers unbedingt erforderlich sind. Mit PhpMyAdmin ist es selbst für Anfänger sehr einfach, ein Problem zu erkennen und ein grundlegendes Verständnis für dieses Problem zu haben. Wenn ein Wert grün ist, sind wir gut. Wenn es rot ist, braucht es etwas Aufmerksamkeit. Es erlaubt uns auch zu verstehen, dass wir einige Fortschritte gemacht haben. Wenn wir unseren Server neu starten, werden diese Sitzungsvariablen alle gelöscht. Wenn wir Änderungen vorgenommen haben, können wir sofort sehen, ob wir etwas bewirkt haben.

EXPLAIN: Den Gibberish verstehen

Nachdem wir festgestellt haben, dass wir einige Optimierungen vornehmen müssen, schauen wir uns einige der Tools an, die wir verwenden werden, bevor wir unsere Probleme finden. Das erste und wahrscheinlich hilfreichste Tool ist die Verwendung von EXPLAIN. EXPLAIN gibt uns grundsätzlich unseren Plan zur Ausführung von Abfragen. Hier erfahren wir, was MySQL mit dieser Abfrage vor ihrer Ausführung vorhat.

Ohne EXPLAIN nachzulesen, bedeutet Ihnen die Ausgabe möglicherweise nicht viel. Schauen wir uns anhand einer Tabelle, die ich für ein früheres Lernprogramm erstellt habe, einen nicht optimierten Ausführungsplan an. Meine Tabelle hat in diesem Fall nur zwei Felder, eines ist sales_id und das andere ist sale_amount. Hier ist die Abfrage, mit der ich arbeite:

 
	SELECT sales_id, 
	            sale_amount 
	FROM tutorial.sales 
	ORDER BY sale_amount

An der Oberfläche ist dies eine sehr einfache Abfrage. Als Verkaufstisch wird der Tisch jedoch wachsen und wachsen und wachsen. Ich habe 200 Datensätze für das vorherige Tutorial generiert und durch einfaches SELECT mit einer ORDER BY-Klausel hat es tatsächlich einiges länger gedauert, als ich erwartet hätte:

Diese Abfrage mit nur 200 Datensätzen hat uns 0,15 Sekunden gekostet. Lassen Sie uns EXPLAIN verwenden, um zu verstehen, wie MySQL diese Abfrage sieht. Klicken Sie einfach auf den Link "SQL erklären", um die Ergebnisse anzuzeigen:

Wie die meisten Dinge macht dies nur dann Sinn, wenn Sie verstehen, was gesagt wird. Für jemanden, der noch nie eine EXPLAIN für eine Abfrage ausgeführt hat, kann das genauso gut in Hieroglyphen geschrieben werden. Mal sehen, ob wir etwas Verständlicheres übersetzen können.

Der select_type sagt uns, dass MySQL dieses SELECT als einfach ansieht, zu einer Tabelle gehen und verarbeiten. Wenn es eine Union oder eine Unterabfrage gäbe, würde dies zeigen, welchen Teil der SELECT-Anweisung dies aufrufen würde. Zum Beispiel, wenn ich eine Abfrage erstelle, die eine Unterabfrage enthält:

1
2	SELECT sale_amount as amount
3	FROM sales
4	WHERE sales_id IN (SELECT sales_id FROM sales_force WHERE sales_id = 4)

Wir bekommen eine Erklärung dafür:

Was uns über die Abfrage selbst erzählt. In diesem Fall hat sich unser select_type dahingehend geändert, dass die erste Abfrage die primäre ist, und dann wird MySQL die Unterabfrage ausführen, bei der es sich um eine Ansicht handelt. Daher muss eine weitere Unterabfrage ausgeführt werden. Daher enden wir mit den drei separaten Abfragen IDs. Das MySQL-Referenzhandbuch enthält alle möglichen Werte:

Zurück zu unserem ursprünglichen Beispiel:

Der Typ ist derjenige, auf den Sie achten müssen, da er Ihnen sagt, ob MySQL die gesamte Tabelle scannen wird oder ob es einen Index verwendet, um die Ergebnisse schnell zu finden. Das ist die primäre Spalte, die Sie bei der Optimierung Ihrer Abfragen berücksichtigen sollten. Von der Reihenfolge gut bis schlecht sind die Werte:

system, wobei die Systemtabellen verwendet werden, um einen Wert zurückzugeben
const, wobei der Primärschlüssel verwendet wird, um eine Zeile zurückzugeben
eq_ref, Abfrage wird auf Primärschlüssel oder eindeutigen Schlüssel verbunden
ref, Abfrage wird im Index verknüpft und stimmt nur mit wenigen Zeilen überein
fulltext, verbunden mit Volltextindex
ref_or_null führt eine Referenz durch, muss aber auch nach Nullzeilen suchen
index_merge, join in der Ausgabezeile enthält Indizes
unique_subquery, indizierte Suchfunktion mit eindeutigen Werten
index_subquery, wie der letzte, jedoch keine eindeutigen Werte
range, Zeilen in einem bestimmten Bereich werden mithilfe des Index abgerufen, um die Zeilen auszuwählen
index, schlecht, aber zumindest mit einem Indexbaum zum Scannen
all, wirklich schlecht, den gesamten Tisch scannen

Wenn Sie beginnen möchten, müssen Sie alle Abfragen optimieren, die entweder vom Typ des index oder von all sind. Wenn Sie Ihre Anwendung von diesen beiden Typen befreien können, wird sich Ihre Leistung verbessern. Hier, meine Freunde, fangen Sie an.

Der Rest der Spalten befasst sich mit den Indizes, die MySQL verwendet, und der Anzahl der Zeilen, die gescannt werden müssen, bevor festgestellt werden kann, ob ein gültiges Ergebnis vorliegt. Wenn Sie die Typen "index" und "all" entfernen, sind diese hilfreich, um genau zu verstehen, welchen Index MySQL zur Ausführung dieser Abfrage verwendet. Um eine Abfrage nach oben zu verschieben, müssen Sie Ihre Indizes optimieren, um die Leistung zu verbessern. Zur Veranschaulichung werde ich mich daran halten, "all" oder vollständige Tischscans zu entfernen.

Die letzte Spalte ist die "extra" Spalte. Die zusätzliche Spalte enthält Informationen zur Abfrage, ob eine WHERE-Klausel verwendet wird oder nicht, ob es sich um ein unmögliches WHERE handelt oder nicht. Dies bedeutet, dass diese Abfrage immer einen NULL-Wert zurückgibt, da die WHERE-Klausel die Ausführung unmöglich macht. Der einzige Wert, den wir sehr genau beachten und loswerden müssen, ist der "Using filesort", den wir in unserem Beispiel haben. Wenn Sie diesen Wert sehen, muss MySQL die Ergebnisse erneut durchlaufen, um die Werte zu sortieren. Also, im Fall unserer ursprünglichen Abfrage:

 
	SELECT sales_id, 
	            sale_amount 
	FROM tutorial.sales 
	ORDER BY sale_amount

MySQL scannt nicht nur die gesamte Tabelle, sondern muss sie aufgrund unserer ORDER BY-Anweisung auch zweimal scannen, um die Ergebnisse zu sortieren. Das ist offensichtlich doppelt schlecht. Wir werden diese und viele weitere Abfragen in den folgenden Abschnitten optimieren.

MySQL Profiler: Nachdem die Abfrage ausgeführt wurde

In MySQL 5.0.37 wurde ein weiteres Tool für die Optimierung verfügbar, nämlich der MySQL-Profiler. Darüber hinaus hat phpMyAdmin die Unterstützung für diese Funktion in Version 2.11 hinzugefügt. Wenn Sie also beide Versionen zur Verfügung haben, können Sie der Optimierung ein weiteres Tool hinzufügen.

Der MySQL Profiler informiert Sie über die Engpässe unserer Abfragen. Es ermöglicht uns zu sehen, was während der tatsächlichen Ausführung unserer Abfragen passiert, und was EXPLAIN tut, indem der Ausführungsplan vorher angegeben wird. Mal sehen, welche Informationen wir von phpMyAdmin aus meiner ursprünglichen fehlerhaften Abfrage erhalten können:

Wenn wir unter unserer Abfrage auf das Kontrollkästchen "Profiling" klicken, öffnet sich eine neue Welt mit:

phpMyAdmin gibt die tatsächlichen Ausführungszeiten der bereitgestellten Abfrage an. Wir können jetzt die Engpässe erkennen, bei denen unsere Abfragen oder sogar die Struktur auf Tabellenebene angegangen werden sollten. Vielleicht sehen wir in Protokolldateien die Notwendigkeit, dass diese Tabelle wirklich nicht so oft geschrieben wird, wie sie gelesen wird. Daher können wir sie jetzt anstelle von InnoDB auf MyISAM umstellen.

Die Verwendung von phpMyAdmin bei Verwendung des MySQL-Profilers hat einen kleinen Nachteil. Der Profiler basiert auf der Sitzung, und phpMyAdmin zerstört die Sitzung bei jedem Seitenaufruf. Das Problem besteht darin, dass wir keinen haben Weg, um eine laufende Summe der Profildaten zu behalten, aber es gibt einen Weg, phpMyAdmin auszutricksen, wenn auch auf klobige Weise:

 
	SET profiling = 1; 
 
	SELECT sales_id, 
	            sale_amount 
	FROM tutorial.sales 
	ORDER BY sale_amount; 
 
	SHOW profiles;

Dass zum... bringt:

Da wir mehrere Abfragen ausführen, müssen Sie das Trennzeichen verwenden. Das zeigt, dass meine Abfrage query_id 1 lautet. Jedes Mal, wenn ich diese Abfrage ausführe, ist sie immer noch query_id 1, da meine Sitzung beim Start zerstört wird. Ich bin nicht sicher, ob dies beabsichtigt ist, ein Fehler oder eine Unwissenheit meinerseits, dass phpMyAdmin die Sitzung mit dem Befehl QUIT zerstört, aber wir können dieses Problem nur ein wenig umgehen. MySQL hat eine wunderbare Beschreibung der Verwendung des Profilers von Robin Schumacher, und ich werde ein wenig von Robins Abfrage verwenden, um die Anzahl der Operationen in phpMyAdmin zu ermitteln:

 
	SET profiling = 1; 
 
	SELECT sales_id, 
	            sale_amount 
	FROM tutorial.sales 
	ORDER BY sale_amount; 
 
	SELECT min(seq) as sequence, 
	            state, 
	            count(*) as operations, 
	            round(sum(duration),5) as duration 
	FROM information_schema.profiling 
	WHERE query_id = 1 
	GROUP by state 
	ORDER by seq;

Wiederum nicht ideal mit phpMyAdmin, aber am Ende bekommen wir immer noch, was wir wollen:

Protokolldateien und globale Vars: Abrufen der Abfragen

Bevor wir alles zusammenstellen, was wir gelernt haben, schauen wir uns auch an, wie Abfragen mithilfe der Protokolldateien von MySQL erfasst werden. Wir können jede Abfrage erfassen, die MySQL in der Tabelle mysql.general_log ausführt. Durch Ausführen dieses Befehls:

1
2	SET GLOBAL general_log = 'ON';
3	SET GLOBAL log_output = 'TABLE';

Wir können jetzt einen Datensatz für alle ausgeführten Abfragen haben, unabhängig von der Quelle. Obwohl dieser Vorgang teuer ist und ich ihn nicht in einer Produktionsumgebung ausführen würde, bietet er uns eine klare und präzise Methode, um alle unsere Abfragen und die Reihenfolge ihrer Ausführung aus unseren Anwendungen abzurufen. Kurz gesagt, das ist das wertvollste Tool zur Optimierung von SQL-Abfragen, das Sie in Ihrer Toolbox haben. Durch das Setzen dieser beiden GLOBAL-Variablen haben wir den letzten Schritt, um einige praktische Optimierungstechniken zu erhalten.

Hier ist eine abgekürzte Ausgabe der Tabelle mysql.general_log mit dieser Abfrage:

 
	SELECT event_time, 
	            command_type, 
	            argument 
	FROM mysql.general_log 
	ORDER BY event_time

produziert dies:

Ich habe im Grunde meine Anfrage, zusammen mit allem, was phpMyAdmin im Hintergrund getan hat. Wenn ich die Tabelle vor jedem neuen Befehl entleere, kann ich mit jeder Seitenansicht oder jedem AJAX-Aufruf aus meinen Anwendungen arbeiten. Um das Protokoll zu leeren, TRUNCIEREN wir die Tabelle einfach wie folgt:

1
2	TRUNCATE mysql.general_log

Truncate ist eine viel bessere Anweisung als DELETE FROM, da die DELETE-Anweisung Zeile für Zeile löscht, wobei TRUNCATE die gesamte Tabelle auf einmal leert.

Sobald Sie mit Ihrer Optimierung fertig sind, müssen Sie Ihr Abfrageprotokoll einfach mit diesem Befehl deaktivieren:

1
2	SET GLOBAL general_log = 'OFF';

Das allgemeine Protokoll wird mit der Zeit teuer und verlangsamt sicherlich die Leistung Ihrer Anwendung. Ich halte es zwischen meinen Optimierungen einfach ausgeschaltet, damit ich ein organisches Gefühl für die Leistung dessen bekomme, was ich schreibe. In der Entwicklung bleibt das Protokoll für langsame Abfragen jedoch immer aktiviert, da ich meine langsameren Abfragen als schnelles Optimierungstool sehen möchte. Sie können dies leicht tun:

1
2	SET GLOBAL slow_query_log = 'ON';
3	SET GLOBAL log_queries_not_using_indexes = 'ON';
4	SET GLOBAL log_output = 'TABLE';

und wir können dies auf unserer Registerkarte "Variablen" auf unserer Begrüßungsseite überprüfen:

Um die Ausgabe zu sehen, müssen wir nur entweder das mysql.slow_log überprüfen oder eine Abfrage wie die folgende verwenden:

1
2	SELECT sql_text
3	FROM mysql.slow_log

Was mir die tatsächlichen Abfragen gibt, die als langsam protokolliert wurden:

Zusammenfügen: Wir sprechen über Übung

Jetzt können wir dies zusammenfassen und phpMyAdmin als relativ anständiges Tool zur Abfrageoptimierung verwenden. Beginnen wir mit dem ersten Abfragebeispiel:

 
	EXPLAIN 
	SELECT sales_id, 
	            sale_amount 
	FROM tutorial.sales 
	ORDER BY sale_amount

Welches ergibt eine Ausgabe von:

Wir wissen, dass wir mindestens einen INDEX für diese Tabelle benötigen. Lassen Sie uns innehalten und überlegen, wie diese Tabelle verwendet wird. Es ist eine einfache Nachschlagetabelle, um einer sales_force-Tabelle beizutreten und uns mitzuteilen, dass sie einen Verkauf getätigt haben, der dem erfassten Betrag entspricht. Wenn wir uns nur gegen diese Tabelle in der sales_id anmelden, müssen wir dies durch Klicken auf den Detaillink indizieren:

Wir können diesen Index dann einfach so definieren:

Unsere ursprüngliche Abfrage gibt uns immer noch einen vollständigen Scan, aber in einer praktischen Anwendung:

 
	SELECT sfn.first_name, 
	            sfn.last_name, 
	            s.sale_amount 
 
	FROM sales_force_normalized sfn 
 
	INNER JOIN sales s 
	ON sfn.sales_id = s.sales_id

Mal sehen, ob das besser ist:

Jetzt kommen wir irgendwohin. Wenn wir jedoch so etwas tun:

1
2	SELECT max(sale_amount)
3	FROM sales

Dann sind wir wieder im selben Boot und machen einen vollständigen Scan des Tisches. In diesem Fall können wir einfach den Index bearbeiten und den sale_amount hinzufügen:

Was uns von wirklich schlecht zu nicht sehr schlecht verbessert:

Oder wir können einen neuen Index nur für den Betrag hinzufügen:

Und wir haben das wunderbare Ergebnis von:

Das bedeutet, dass MySQL nicht einmal die Tabelle öffnen muss, sondern nur in den Index schauen muss. Wir haben jetzt das absolut optimale Niveau für diese COUNT-Funktion erreicht. Überprüfen Sie, wie lange es gedauert hat, diese Abfrage jetzt auszuführen:

Klicken Sie in der Abfrage auf das Kontrollkästchen Profilerstellung, um jetzt Engpässe anzuzeigen:

Reale Welt: Es wird etwas schwieriger

Wir haben mit vorgetäuschten Abfragen und vorgetäuschten Datenbanken gespielt, aber lassen Sie uns dieses Tutorial auf die Probe stellen. Ich habe eine Standard-WordPress-Installation mit nur dem Lorem Ipsum-Plugin, um ungefähr 5000 Beiträge und 11.000 Kommentare hinzuzufügen, sodass wir MySQL bei der Auswahl nur ein wenig belasten können.

Beginnen wir erneut mit der Protokollierung unserer Abfragen von phpMyAdmin und kürzen auch die langsamen und allgemeinen Protokolle, damit wir sehen können, was passiert, wenn wir eine Seite aus WordPress laden:

1
2	SET GLOBAL general_log = 'ON';
3	TRUNCATE mysql.slow_log;
4	TRUNCATE mysql.general_log;

Es wird einige Artefakte im general_log geben, da phpMyAdmin einige Aktivitäten in MySQL verursacht, aber wir sollten in der Lage sein, alles in Ordnung zu bringen, wenn ich meine Indexseite zu diesem Zeitpunkt aus WordPress neu lade und wenn wir eine LIKE-Bedingung verwenden, wir kann meist nur WordPress-Ergebnisse erhalten, da den Tabellen wp_ vorangestellt ist:

 
	SELECT event_time, 
	       command_type, 
	       argument 
	FROM mysql.general_log 
	WHERE argument LIKE "%wp_%" 
	ORDER BY event_time

Was uns ein vernünftiges Ergebnis gibt von:

Jetzt wissen wir, dass WordPress uns einfach 11 Fragen zum Laden der Indexseite mit einer hübschen Vanille-Installation gibt. Lassen Sie uns etwas Optimiertes finden, das sie möglicherweise übersehen haben. Wenn wir die allererste Abfrage nehmen, die ausgeführt wird, wenn WordPress geladen wird:

 
	EXPLAIN SELECT option_name, 
	                         option_value 
	FROM wp_options 
	WHERE autoload = 'yes'

Wir stellen fest, dass dies nicht optimiert ist:

Werfen wir einen Blick darauf, was sie mit phpMyAdmin gemacht haben:

Wir sehen, dass es einen Index für option_name gibt, aber keinen Index für das automatische Laden. Dies ist die Bedingung, die auf der Indexseite angegeben ist. Lassen Sie es uns hinzufügen und sehen, ob wir die Kerninstallation von WordPress nicht ein wenig optimieren können:

Da Autoload varchar ist und entweder "Ja" oder "Nein" von dem, was ich sehe, kann ich meinen Indexwert auf 1 begrenzen. Das heißt, es sieht jetzt entweder "y" oder "n", was unsere Zeit noch weiter verkürzt. Lassen Sie uns die EXPLAIN sehen, nachdem wir optimiert haben:

Wir sind vom wirklich schlechten zum viertbesten Typ übergegangen. Nicht schlecht für ein paar Minuten Arbeit. Zugegeben, WordPress hat diesen Wert nicht verschluckt, aber je nach Belastung Ihres Blogs hilft jedes kleine bisschen. Zugegeben, das Schreiben dauert länger, da wir für jede geschriebene Zeile unser "y" oder "n" indizieren müssen.

Wenn wir nur ein wenig weiter gehen, können wir den MySQL Profiler auch in Aktion sehen, indem wir nur das Kontrollkästchen "Profiling" aktivieren. Jetzt sehen wir, dass unsere Anfrage wirklich gut läuft:

Abschluss

Die Optimierung ist nicht einfach und macht auch nicht viel Spaß. Wenn Sie diesen Entwicklungsschritt jedoch ignorieren, wird er Sie immer wieder verfolgen. Ich glaube, dass es relativ einfach ist, die Tools in phpMyAdmin zu verwenden, um einen ziemlich guten Optimierungsblick auf Ihre Anwendungen zu erhalten. Allerdings werden neue Tools immer wieder hinzugefügt, wie z. B. Jet Profiler, der das, was ich gerade getan habe, in Echtzeit und grafisch übersetzt.

Es ist nicht schwierig oder sehr zeitaufwändig, sich der Optimierung über phpMyAdmin zu nähern. Es braucht ein wenig Geduld, um zu lernen, wie es geht und was getan werden kann. Ich hoffe, dass ich Ihnen die Werkzeuge gegeben habe, um Ihre Ansätze ein bisschen effektiver zu gestalten. Bitte teilen Sie mir Ihre Meinung im Kommentarbereich mit.