Share
Ich habe phpMyAdmin über ein Jahrzehnt lang verwendet. In meinen frühen Jahren mit dem Tool brauchte ich einfach etwas, das mir die Tabellenstruktur anzeigen und die Daten schnell wiedergeben konnte. Da meine Bedürfnisse gewachsen sind, sind auch die in phpMyAdmin enthaltenen Tools enthalten, sodass ich auch mit Optimierung als primäres MySQL-Tool zurückkehren kann.
Ich hatte das Vergnügen, mit verschiedenen Datenbanken zu arbeiten. Jeder hat seine Nachteile und jeder hat seine Stärken. Wenn ich die Wahl habe, neige ich dazu, zu MySQL zurückzukehren, obwohl ich zu billig bin, um MySQL Enterprise zu kaufen. Stattdessen mache ich es mit phpMyAdmin als Hauptprofilierungswerkzeug. Es funktioniert gut für mich, aber ich musste einige Nachforschungen anstellen, um zu verstehen, was ich beim Profilieren meiner Anwendungen sehe. Ich hoffe, dass ich das so weitergeben kann, dass es vom Anfänger bis zum erfahrenen Profi verstanden werden kann.
Die Optimierung braucht Zeit. Manager, Kunden und Kollegen in dieser Angelegenheit hören nicht gern, dass ein Projekt aufgrund von Optimierungen hinter dem Zeitplan zurückbleibt. Oft drängen wir die Optimierung, um diese Benchmarks zu erreichen. Am Ende tun wir aber keinen Gefallen. Die schönste Webanwendung der Welt wird Sie wiederverwenden, wenn es 10 Sekunden dauert, um jede Seite zu laden. Wenn wir mit der Optimierung bis zum Ende unserer Projekte warten, besteht ebenfalls die Chance, dass viel mehr Arbeit zu erledigen ist, als wenn wir im Verlauf des Projekts nachgeprüft hätten.
Noch ein paar Anmerkungen, bevor wir uns mit Fleisch und Kartoffeln beschäftigen. Erstens werde ich nicht in MySQL Tuning einsteigen, da es etwas außerhalb des Rahmens dieses Tutorials liegt. Während Tuning Optimierung ist, ist es meiner Meinung nach ein Thema für sich. Ich werde kurz einige Möglichkeiten erwähnen, um die Optimierung Ihres Servers zu optimieren, aber die Erwähnungen werden kurz sein. Außerdem werde ich hauptsächlich MyISAM-Tabellen und keine InnoDB-Tabellen betrachten. Als Faustregel gilt: Wenn Sie viele Daten schreiben, verwenden Sie InnoDB. Wenn Sie jedoch viel mehr SELECT verwenden, verwenden Sie MyISAM. Ich komme auch nicht auf die Tabellenebene REPAIR, OPTIMIZE, CHECK und ANALYZE, da dieses Tutorial die Abfrageoptimierung mit phpMyAdmin behandelt. Dies ist wiederum etwas außerhalb des Rahmens dieses Tutorials.
Schließlich werde ich WordPress als ein Beispiel aus der realen Welt betrachten. Ich werde der Erste sein, der Ihnen mitteilt, dass ich kein Experte für WordPress bin, aber ich kann die generierten Abfragen mit den Besten betrachten. Von dem, was ich gesehen habe, ist die Datenbank mit WordPress gut indiziert. Sobald wir jedoch Dinge hinzufügen, die sich außerhalb dieser Hauptkerndateien befinden, sind diese Indizes möglicherweise nicht das Beste für das, was wir brauchen.
"Optimierung braucht Zeit. Manager, Kunden und Kollegen in dieser Angelegenheit hören nicht gern, dass ein Projekt aufgrund von Optimierung hinter dem Zeitplan zurückliegt."
Die kurze Antwort lautet ja.
Die lange Antwort lautet: phpMyAdmin gibt uns die Chance zu sehen, ob wir unsere Abfragen optimieren müssen und wie dringend wir sie optimieren müssen. Ich könnte mir vorstellen, dass Sie diesen Bildschirm mehr als einmal gesehen haben, wenn Sie phpMyAdmin verwendet haben:
Dies ist der Standard-Startbildschirm für phpMyAdmin. Wenn Sie nicht nach Optimierungsmöglichkeiten suchen, können Sie direkt zu Ihren Tischen im Menü auf der linken Seite gehen und niemals das Tab-Menü oben sehen. In diesem Menü, insbesondere den Registerkarten Status und Variablen, werden wir beginnen.
Beginnen wir mit dem Status-Bildschirm, der möglicherweise das wichtigste von phpMyAdmin ist:
Dies ist der obere Teil des Statusbildschirms. Es gibt zwar einige interessante Daten, aber wenn Sie noch nie unter die Schriftrolle gegangen sind, haben Sie einige wichtige Informationen übersehen. Der Kürze halber möchte ich zwei sehr einfache Gegenwerte betrachten, die ich besessen habe, die ersten aus meiner Testumgebung:
Die beiden Werte, auf die Sie genau achten müssen, sind Handler_read_rnd und Handler_read_rnd_next. Wenn diese beiden Werte rot sind, gibt es einige Abfragen, die überprüft werden müssen, da MySQL eine SELECT-Anweisung ausführt und die gesamte Tabelle liest. In einigen Fällen kann dies beabsichtigt sein, da beim Schreiben eines Index für eine Tabelle der Schreibvorgang etwas länger dauert und der Speicherplatz etwas größer ist. Wenn Sie jedoch so etwas sehen:
Die Chancen stehen gut, das war nicht beabsichtigt. 141 Millionen Anfragen zum Lesen einer Zeile an einer festen Position und 16 Milliarden Anfragen zum Lesen der nächsten Zeile bedeuten wahrscheinlich, dass uns ein oder zwei Indizes fehlen (tausend). Offensichtlich wächst diese Zahl mit der Anzahl der Anfragen. Je mehr Suchmaschinen Ihre Website indiziert oder je mehr Besucher Sie haben, desto größer wird ein kleiner verfehlter Index. Vollständige Tischscans sind der Feind, und Sie können so schnell erkennen, wie nahe der Feind an den Toren ist.
Eine weitere großartige Tabelle zur Überprüfung der Abfrageleistung enthält einen direkten Blick auf die Auswahl- und Indexfunktionen:
Diese Tabelle schenkt Ihren Verknüpfungen besondere Aufmerksamkeit. Eine gefährliche Kombination verwendet und indexiert nicht für beide Tabellen, da Ihre vollständigen Tabellenscans mit der Anzahl der verwendeten Joins exponentiell ansteigen. Je normaler Ihre Tabellen sind, desto mehr müssen Sie auf Ihre Indizes sowie auf die Definition der Felder achten, denen Sie beitreten.
Abhängig von einer globalen Variablen möchten Sie schließlich auch diese Variablentabelle überprüfen:
Wenn Sie langsame Abfragen protokollieren, zeigt dieser Variablenzähler die für die Beobachtung identifizierte Anzahl an, abhä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 für die Optimierung Ihres MySQL-Servers absolut unerlässlich sind. PhpMyAdmin macht es sogar dem Neuling wirklich leicht, ein Problem zu erkennen und ein grundlegendes Verständnis dafür zu haben, was dieses Problem sein könnte. Wenn ein Wert grün ist, sind wir gut. Wenn es rot ist, braucht es etwas Aufmerksamkeit. Dadurch können wir auch verstehen, dass wir einige Fortschritte erzielt haben. Wenn wir unseren Server neu starten, werden alle diese Sitzungsvariablen gelöscht. Wenn wir Änderungen vorgenommen haben, können wir sofort sehen, wenn wir etwas bewirken.
Nachdem wir nun festgestellt haben, dass wir einige Optimierungen vornehmen müssen, wollen wir uns einige der Tools ansehen, die wir verwenden werden, bevor wir unsere Probleme finden. Das erste und wahrscheinlich das hilfreichste Werkzeug ist die Verwendung von EXPLAIN. EXPLAIN gibt uns grundsätzlich unseren Abfrageausführungsplan. Dies sagt uns, was MySQL vor dieser Ausführung mit dieser Abfrage vorhat.
Ohne sich über EXPLAIN informieren zu müssen, bedeutet die Ausgabe für Sie möglicherweise nicht viel. Lassen Sie uns anhand einer Tabelle, die ich für ein früheres Tutorial erstellt habe, einen nicht optimierten Ausführungsplan betrachten. Meine Tabelle hat in diesem Fall nur zwei Felder, eines ist sales_id und das andere ist sale_amount. Hier ist die Frage, mit der ich arbeite:
SELECT sales_id, sale_amount FROM tutorial.sales ORDER BY sale_amount
An der Oberfläche ist dies eine sehr einfache Abfrage. Als Verkaufstisch wird der Tisch jedoch wachsen und wachsen und wachsen. Ich habe 200 Datensätze für das vorherige Tutorial generiert, und durch das Ausführen einer einfachen SELECT-Anweisung mit einer ORDER BY-Klausel hat es tatsächlich etwas länger gedauert, als ich erwartet hätte:
Diese Abfrage mit nur 200 Datensätzen kostete uns 0,15 Sekunden. Verwenden Sie EXPLAIN, um zu verstehen, wie MySQL diese Abfrage sieht. Klicken Sie einfach auf den Link "SQL erklären", um die Ergebnisse anzuzeigen:
Wie die meisten Dinge ist dies nicht sinnvoll, wenn Sie nicht verstehen, was gesagt wird. Für jemanden, der noch nie eine EXPLAIN-Anweisung für eine Abfrage ausgeführt hat, kann dies ebenso in Hieroglyphen geschrieben werden. Mal sehen, ob wir etwas Verständlicheres übersetzen können.
Der select_type sagt uns, dass MySQL dieses SELECT als einfach betrachtet. Gehen Sie zu einer Tabelle und gehen Sie vor. Wenn es eine Union oder eine Unterabfrage gäbe, würde dies zeigen, welchen Teil der SELECT-Anweisung diese aufrufen würde. Zum Beispiel, wenn ich eine Abfrage mit einer Unterabfrage erstelle:
SELECT sales_amount als Betrag FROM Umsatz WHERE sales_id IN (SELECT sales_id FROM sales_force WHERE sales_id = 4)
Wir erhalten eine Erklärung davon:
Was uns über die Abfrage selbst sagt. In diesem Fall hat sich unser select_type geändert, um zu sagen, dass die erste Abfrage die primäre ist, und dann wird MySQL die Unterabfrage ausführen, die eine Ansicht ist. Daher gibt es eine weitere Unterabfrage, die ausgeführt werden muss Ids. Das MySQL-Referenzhandbuch enthält alle möglichen Werte:
Zurück zu unserem ursprünglichen Beispiel:
Der Typ ist derjenige, auf den Sie achten sollten, da er Ihnen sagt, ob MySQL die gesamte Tabelle durchsucht oder ob es einen Index verwendet, um die Ergebnisse schnell zu finden. Dies ist die primäre Spalte, die Sie beim Optimieren Ihrer Abfragen anzeigen müssen. Von der Ordnung gut bis schlecht sind die Werte:
Wo Sie anfangen möchten, ist die Optimierung jeder Abfrage, die entweder der Typ ist Index oder alles. Wenn Sie Ihre Anwendung von diesen beiden Typen befreien können, wird sich Ihre Leistung verbessern. Hier, meine Freunde, fängt ihr an.
Die restlichen Spalten behandeln die Indizes, die MySQL verwendet, und die Anzahl der Zeilen, die geprüft werden müssen, bevor ein gültiges Ergebnis ermittelt werden kann. Wenn Sie die Typen "index" und "all" loswerden, sind diese sehr hilfreich, um genau zu verstehen, welchen Index MySQL zum Ausführen dieser Abfrage verwendet. Um eine Abfrage in die Kontaktliste zu verschieben, beginnen Sie mit der Optimierung Ihrer Indizes, um die Leistung zu verbessern. Zur Veranschaulichung halte ich mich daran, "alle" oder vollständige Tischscans zu entfernen.
Die letzte Spalte ist die "zusätzliche" Spalte. Die zusätzliche Spalte enthält Informationen über die Abfrage, ob eine WHERE-Klausel verwendet wird oder nicht, ob es sich um ein unmögliches WHERE handelt oder nicht, dh diese Abfrage gibt immer NULL zurück, weil die WHERE-Klausel die Ausführung unmöglich macht. Der einzige Wert, den wir sehr genau beachten müssen, ist der "using filesort", den wir in unserem Beispiel haben. Wenn Sie diesen Wert sehen, muss MySQL die Ergebnisse erneut durchgehen, um die Werte zu sortieren. Im Falle unserer ursprünglichen Abfrage:
SELECT sales_id, sale_amount FROM tutorial.sales ORDER BY sale_amount
MySQL scannt nicht nur die gesamte Tabelle, sondern muss sie auch zweimal scannen, um die Ergebnisse aufgrund unserer ORDER BY-Anweisung zu sortieren. Dies ist offensichtlich doppelt schlecht. Wir werden diese Abfrage und viele weitere in den folgenden Abschnitten optimieren.
In MySQL 5.0.37 steht ein weiteres Tool zur Verfügung, das wir zur Optimierung verwenden können, und zwar den MySQL-Profiler. Darüber hinaus hat phpMyAdmin in Version 2.11 Unterstützung für dieses Feature hinzugefügt. Wenn Sie also beide Versionen zur Verfügung haben, können Sie ein weiteres Tool zur Optimierung hinzufügen.
Der MySQL Profiler gibt Informationen zu Engpässen unserer Abfragen. So können wir sehen, was passiert während die tatsächliche Ausführung unserer Abfragen, und umgekehrt, was EXPLAIN tut, dh den Ausführungsplan angeben Vor. Mal sehen, welche Informationen wir von phpMyAdmin aus meiner ursprünglichen fehlerhaften Abfrage erhalten können:
Wenn wir unterhalb unserer Abfrage auf das Kontrollkästchen "Profiling" klicken, öffnet sich eine neue Welt mit:
phpMyAdmin stellt die tatsächlichen Ausführungszeiten der bereitgestellten Abfrage bereit. Wir können jetzt die Engpässe sehen, wo unsere Abfragen oder sogar die Struktur auf Tabellenebene behandelt werden sollten. Vielleicht sehen wir die Notwendigkeit von Protokolldateien, dass diese Tabelle wirklich nicht so geschrieben wird, wie sie gelesen wird. Statt InnoDB können wir sie nun auf MyISAM umstellen.
Die Verwendung von phpMyAdmin bei der Verwendung von MySQL Profiler hat einige Nachteile. Das heißt, dass der Profiler auf der Sitzung basiert und phpMyAdmin die Sitzung in jedem Seitenzugriff zerstört. Das Problem besteht darin, dass wir keinen Weg haben um eine laufende Summe der Profilierungsdaten zu erhalten, aber es gibt eine Möglichkeit, phpMyAdmin zu täuschen, wenn auch auf eine kludige Art und Weise:
SET Profiling = 1; SELECT sales_id, sale_amount FROM tutorial.sales ORDER BY sale_amount; SHOW-Profile;
Was in ... resultiert:
Da wir mehrere Abfragen ausführen, müssen Sie das Trennzeichen verwenden. Dies zeigt an, dass meine Abfrage query_id 1 ist. Jedes Mal, wenn ich diese Abfrage ausführe, ist es immer noch query_id 1, da meine Sitzung beim Start zerstört wird. Ich bin nicht sicher, ob es sich dabei um einen Fehler oder eine Unkenntnis handelt, bei denen phpMyAdmin die Sitzung mit dem Befehl QUIT zerstört, aber wir können dieses Problem nur ein wenig umgehen. MySQL kann sich wunderbar mit dem Profiler von Robin Schumacher auseinandersetzen, 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) als Sequenz, Status, Anzahl (*) als Operationen, Runde (Summe (Dauer), 5) als Dauer FROM information_schema.profiling WHERE query_id = 1 GROUP nach Zustand ORDER nach Seq;
Wiederum nicht ideal mit phpMyAdmin, aber wir bekommen am Ende immer noch, was wir wollen:
Bevor wir alles, was wir gelernt haben, zusammenstellen, werfen wir einen Blick auf die Erfassung von Abfragen mithilfe der MySQL-Protokolldateien. Jede Abfrage, die MySQL ausführt, kann in der Tabelle mysql.general_log erfasst werden. Führen Sie diesen Befehl aus:
SET GLOBAL general_log = 'ON'; SET GLOBAL log_output = 'TABLE';
Wir können jetzt einen Datensatz für alle Abfragen haben, die unabhängig von der Quelle ausgeführt werden. Während dieser Vorgang teuer ist und ich ihn nicht in einer Produktionseinstellung ausführen würde, gibt er uns eine klare und präzise Methode, um alle unsere Abfragen und die Reihenfolge ihrer Ausführung aus unseren Anwendungen zu erhalten. Kurz gesagt, ist dies möglicherweise das wertvollste Tool zur Optimierung von SQL-Abfragen, das Sie in Ihrer Toolbox verwenden. Durch das Setzen dieser beiden GLOBAL-Variablen haben wir den letzten Schritt, um einige praktische Optimierungstechniken zu erhalten.
Hier ist eine abgekü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 das:
Ich habe im Grunde meine Abfrage und alles, was phpMyAdmin im Hintergrund gemacht hat. Wenn ich die Tabelle vor jedem neuen Befehl entleere, habe ich etwas, mit dem ich in jeder Seitenansicht arbeiten kann, oder einen AJAX-Aufruf, den ich aus meinen Anwendungen mache. Um das Protokoll zu leeren, TRUNCATE wir die Tabelle einfach so:
TRUNCATE mysql.general_log
Truncate ist eine viel bessere Anweisung als DELETE FROM, da die DELETE-Anweisung Zeile für Zeile löscht, während TRUNCATE die gesamte Tabelle auf einmal leert.
Sobald Sie mit der Optimierung fertig sind, müssen Sie Ihr Abfrageprotokoll einfach mit diesem Befehl deaktivieren:
SET GLOBAL general_log = 'OFF';
Das allgemeine Protokoll wird mit der Zeit teuer und verlangsamt die Leistung Ihrer Anwendung. Ich halte es zwischen meinen Optimierungen einfach deaktiviert, damit ich ein organisches Gefühl für die Leistung meiner Arbeiten erhalten kann. Das heißt, in der Entwicklung lasse ich das langsame Abfrageprotokoll immer aktiviert, da ich langsamere Abfragen als schnelles Optimierungswerkzeug sehen möchte. Das geht ganz einfach:
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL log_queries_not_using_indexes = 'ON'; SET GLOBAL log_output = 'TABLE';
und wir können dies auf unserer Registerkarte "Variablen" von unserer Begrüßungsseite aus überprüfen:
Um die Ausgabe zu sehen, müssen Sie entweder nur mysql.slow_log überprüfen oder eine Abfrage wie folgt verwenden:
SELECT sql_text FROM mysql.slow_log
Was gibt mir die tatsächlichen Abfragen, die als langsam protokolliert wurden:
Jetzt können wir dies zusammenfassen und phpMyAdmin als relativ anständiges Tool zur Optimierung von Abfragen verwenden. Beginnen wir mit dem ersten Abfragebeispiel:
EXPLAIN SELECT sales_id, sale_amount FROM tutorial.sales ORDER BY sale_amount
Was ergibt eine Ausgabe von:
Wir wissen, dass wir mindestens einen INDEX für diese Tabelle benötigen. Lassen Sie uns anhalten und überlegen, wie diese Tabelle verwendet wird. Es ist eine einfache Nachschlagetabelle, um sich einer sales_force-Tabelle anzuschließen und uns mitzuteilen, dass sie einen Verkauf mit dem erfassten Betrag getätigt haben. Wenn wir uns nur mit dieser Tabelle auf sales_id verbinden, müssen wir das indizieren, indem wir auf den Link "Details" klicken:
Wir können diesen Index dann einfach so definieren:
Unsere ursprüngliche Abfrage liefert immer noch einen vollstä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 irgendwo hin. Wenn wir jedoch so etwas tun:
SELECT max (sale_amount) FROM Verkäufe
Dann sind wir wieder im selben Boot und führen einen vollständigen Scan des Tisches durch. In diesem Fall können wir einfach den Index bearbeiten und den sale_amount hinzufügen:
Was uns von wirklich schlecht bis einfach schlecht verbessert:
Oder wir können einen neuen Index nur für den Betrag hinzufügen:
Und wir haben das wunderbare Ergebnis von:
Dies bedeutet, dass MySQL nicht einmal die Tabelle öffnen muss, sondern nur den Index betrachten muss. Wir haben jetzt das absolut optimale Niveau für diese COUNT-Funktion erreicht. Überprüfen Sie, wie lange es gedauert hat, diese Abfrage jetzt auszuführen:
Lassen Sie uns für eine gute Maßnahme in der Abfrage auf das Kontrollkästchen Profiling klicken, um jetzt Engpässe zu sehen:
Wir haben mit vorgeblichen Abfragen gespielt und Datenbanken vorgetäuscht, aber lassen Sie uns dieses Tutorial auf die Probe stellen. Ich habe eine Standard-WordPress-Installation mit nur dem Lorem-Ipsum-Plugin, um etwa 5000 Beiträge und 11.000 Kommentare hinzuzufügen. Wir können also MySQL nur ein wenig belasten, wenn wir unsere Auswahl treffen.
Beginnen wir, unsere Abfragen erneut in phpMyAdmin zu protokollieren und die langsamen und allgemeinen Protokolle abzuschneiden, sodass wir sehen können, was passiert, wenn wir eine Seite aus WordPress laden:
SET GLOBAL general_log = 'ON'; TRUNCATE mysql.slow_log; TRUNCATE mysql.general_log;
Es gibt ein paar Artefakte im general_log, da phpMyAdmin einige Aktivitäten in MySQL verursacht, aber wir sollten in der Lage sein, alles in Ordnung zu bringen, wenn ich an dieser Stelle meine Indexseite von WordPress neu lade und wenn wir eine LIKE-Bedingung verwenden kann meistens 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
Das gibt uns ein vernünftiges Ergebnis von:
Nun wissen wir, dass WordPress beim Laden der Indexseite mit einer hübschen Vanilla-Installation lediglich 11 Abfragen liefert. Finden wir etwas zu optimiertes, das sie vielleicht übersehen haben. Wenn wir die allererste Abfrage ausführen, die ausgeführt wird, wenn WordPress geladen wird:
EXPLAIN SELECT Optionsname, Optionswert FROM wp_options WHERE autoload = 'yes'
Wir finden, dass dies nicht optimiert ist:
Schauen wir uns an, was sie mit phpMyAdmin gemacht haben:
Wir sehen, dass es einen Index für option_name gibt, aber keinen Index für Autoload. Dies ist die Bedingung, die auf der Indexseite angegeben ist. Lassen Sie uns es hinzufügen und sehen, ob wir die Kerninstallation von WordPress nicht ein bisschen optimieren können:
Da autoload varchar ist und entweder "yes" oder "no" aus dem, was ich sehe, kann ich meinen Indexwert auf 1 beschränken. Das bedeutet, dass jetzt entweder "y" oder "n" angezeigt wird, was unsere Zeit noch weiter verkürzt. Lassen Sie uns EXPLAIN sehen, nachdem wir optimiert haben:
Wir sind vom wirklich schlechten zum viertbesten Typ übergegangen. Nicht schlecht für ein paar Minuten Arbeit. Zugegeben, WordPress hat diesen Wert nicht gewürgt, aber je nach Belastung Ihres Blogs hilft jedes bisschen. Zugegeben, die Schreibvorgänge dauern länger, da wir für jede geschriebene Zeile unser "y" oder "n" indizieren müssen.
Wenn wir noch ein wenig weiter gehen, können Sie den MySQL-Profiler auch in Aktion sehen, indem Sie das Kontrollkästchen "Profiling" aktivieren. Nun sehen wir, dass unsere Anfrage richtig gut läuft:
Optimierung ist weder einfach noch macht es wirklich viel Spaß. Wenn Sie diesen Entwicklungsschritt jedoch ignorieren, wird er immer wieder verfolgt. Ich glaube, es ist relativ einfach, die Tools in phpMyAdmin zu verwenden, um einen guten Optimierungsblick auf Ihre Anwendungen zu erhalten. Das heißt, es werden ständig neue Tools hinzugefügt, z. B. der Jet Profiler, der das, was ich gerade gemacht habe, in Echtzeit umsetzt, und die grafische Natur.
.
Accentsconagua