Statistiken

Verwendung statistischer Daten

Der MySQL Native Driver bietet die Möglichkeit, Statistiken über die Kommunikation zwischen Client und Server zu sammeln. Es gibt zwei Arten von Statistiken:

Client-Statistiken
Verbindungsstatistiken

Wenn die Erweiterung mysqli verwendet wird, können diese Statistiken über zwei API-Aufrufe abgerufen werden:

Hinweis:
Die Statistiken werden für alle Erweiterungen zusammengefasst, die den MySQL Native Driver verwenden. Wenn zum Beispiel sowohl ext/mysql als auch ext/mysqli mit dem MySQL Native Driver kompiliert werden, verändern sowohl die Funktionsaufrufe von ext/mysql als auch von ext/mysqli die Statistiken. Es gibt keine Möglichkeit, herauszufinden, wie sehr ein bestimmter API-Aufruf einer Erweiterung, die gegen den MySQL Native Driver kompiliert wurde, eine bestimmte Statistik beeinflusst hat. Der MySQL PDO Driver, ext/mysql und ext/mysqli können so konfiguriert werden, dass sie optional den MySQL Native Driver verwenden. In diesem Fall werden die Statistiken von allen drei Erweiterungen verändert.

Client-Statistiken abrufen

Auf die Client-Statistiken kann mit der Funktion mysqli_get_client_stats() zugegriffen werden. Für den Funktionsaufruf werden keine Parameter benötigt.

Die Funktion gibt ein assoziatives Array zurück, das die Namen der Statistiken als Schlüssel und die statistischen Daten als Werte enthält.

Auf die Client-Statistiken kann auch mit der Funktion phpinfo() zugegriffen werden.

Verbindungsstatistiken abrufen

Auf die Verbindungstatistiken kann mit der Funktion mysqli_get_connection_stats() zugegriffen werden. Für den Funktionsaufruf werden keine Parameter benötigt.

Die Funktion gibt ein assoziatives Array zurück, das die Namen der Statistiken als Schlüssel und die statistischen Daten als Werte enthält.

Gepufferte und ungepufferte Ergebnismengen

Ergebnismengen können gepuffert oder ungepuffert sein. Mit den Standardeinstellungen arbeiten ext/mysql und ext/mysqli bei normalen Abfragen (ohne vorbereitete Anweisungen) mit gepufferten Ergebnismengen. Gepufferte Ergebnismengen werden auf dem Client zwischengespeichert. Nach der Ausführung der Abfrage werden alle Ergebnisse vom MySQL-Server abgerufen und in einem Zwischenspeicher auf dem Client abgelegt. Der große Vorteil von gepufferten Ergebnismengen besteht darin, dass der Server alle einer Ergebnismenge zugewiesenen Ressourcen freigeben kann, nachdem die Ergebnisse durch den Client abgerufen wurden.

Im Gegensatz dazu werden ungepufferte Ergebnismengen viel länger auf dem Server gehalten. Wenn der Speicherbedarf auf dem Client reduziert werden soll und dafür eine höhere Last auf dem Server in Kauf genommen werden kann, sollten ungepufferte Ergebnisse verwendet werden. Wenn die Serverlast hoch ist und die Werte für ungepufferte Ergebnismengen hoch sind, sollte in Betracht gezogen werden, die Last auf die Clients zu verlagern. Clients sind in der Regel besser skalierbar als Server. Last bezieht sich nicht nur auf Speicherpuffer - der Server muss auch andere Ressourcen offen halten, z. B. Datei-Deskriptoren und Threads, bevor eine Ergebnismenge freigegeben werden kann.

Vorbereitete Anweisungen (Prepared Statements) verwenden standardmäßig ungepufferte Ergebnismengen. Mit der Funktion mysqli_stmt_store_result() kann aber bei Bedarf die Pufferung von Ergebnismengen aktiviert werden.

Vom MySQL Native Driver zurückgegebene Statistiken

Die folgenden Tabellen enthalten eine Liste von Statistiken, die von den Funktionen mysqli_get_client_stats() und mysqli_get_connection_stats() zurückgegeben werden.

**Von mysqlnd zurückgegebene Statistiken: Netzwerk**
Statistik	Bereich	Beschreibung	Hinweise
`bytes_sent`	Verbindung	Die Anzahl der von PHP an den MySQL-Server gesendeten Bytes	Kann verwendet werden, um die Effizienz des Komprimierungsprotokolls zu überprüfen
`bytes_received`	Verbindung	Die Anzahl der vom MySQL-Server empfangenen Bytes	Kann verwendet werden, um die Effizienz des Komprimierungsprotokolls zu überprüfen
`packets_sent`	Verbindung	Die Anzahl der gesendeten MySQL-Client-Server-Protokollpakete	Wird zur Fehlersuche in der Implementierung des Client-Server-Protokolls verwendet
`packets_received`	Verbindung	Die Anzahl der empfangenen MySQL-Client-Server-Protokollpakete	Wird zur Fehlersuche in der Implementierung des Client-Server-Protokolls verwendet
`protocol_overhead_in`	Verbindung	Der Overhead des MySQL-Client-Server-Protokolls für eingehenden Datenverkehr in Bytes. Derzeit wird nur der Paket-Header (4 Bytes) als Overhead betrachtet. protocol_overhead_in = packets_received * 4	Wird zur Fehlersuche in der Implementierung des Client-Server-Protokolls verwendet
`protocol_overhead_out`	Verbindung	Der Overhead des MySQL-Client-Server-Protokolls für ausgehenden Datenverkehr in Bytes. Derzeit wird nur der Paket-Header (4 Bytes) als Overheadbetrachtet. protocol_overhead_in = packets_received * 4	Wird zur Fehlersuche in der Implementierung des Client-Server-Protokolls verwendet
`bytes_received_ok_packet`	Verbindung	Die Gesamtgröße der mit dem MySQL-Client-Server-Protokoll empfangenen OK-Pakete in Bytes. Die OK-Pakete können eine Statusmeldung enthalten, deren Länge variieren kann, weshalb die Größe eines OK-Pakets nicht festgelegt ist.	Wird zur Fehlersuche in der Implementierung des CS-Protokolls verwendet. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`packets_received_ok`	Verbindung	Die Anzahl der mit dem MySQL-Client-Server-Protokoll empfangenen OK-Pakete	Wird zur Fehlersuche in der Implementierung des CS-Protokolls verwendet. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`bytes_received_eof_packet`	Verbindung	Die Gesamtgröße der mit dem MySQL-Client-Server-Protokoll empfangenen EOF-Pakete in Bytes. Die Größe von EOF kann je nach Serverversion variieren. Außerdem kann EOF eine Fehlermeldung enthalten.	Wird zur Fehlersuche in der Implementierung des CS-Protokolls verwendet. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`packets_received_eof`	Verbindung	Die Anzahl der mit dem MySQL-Client-Server-Protokoll empfangenen EOF-Pakete. Wie bei anderen Paketstatistiken erhöht sich die Anzahl der Pakete auch dann, wenn PHP nicht das erwartete Paket, sondern z. B. eine Fehlermeldung empfängt.	Wird zur Fehlersuche in der Implementierung des CS-Protokolls verwendet. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`bytes_received_rset_header_packet`	Verbindung	Die Gesamtgröße der mit dem MySQL-Client-Server-Protokoll empfangenen Header-Pakete der Ergebnismenge in Bytes. Die Größe der Pakete variiert in Abhängigkeit von der Nutzlast (`LOAD LOCAL INFILE`, `INSERT`, `UPDATE`, `SELECT`, Fehlermeldung).	Wird zur Fehlersuche in der Implementierung des CS-Protokolls verwendet. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`packets_received_rset_header`	Verbindung	Die Anzahl der mit dem MySQL-Client-Server-Protokoll empfangenen Header-Pakete der Ergebnismenge	Wird zur Fehlersuche in der Implementierung des CS-Protokolls verwendet. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`bytes_received_rset_field_meta_packet`	Verbindung	Die Gesamtgröße der mit dem MySQL-Client-Server-Protokoll empfangenen Metadaten-Pakete (Spalteninformationen) der Ergebnismenge in Bytes. Die Größe hängt natürlich von den Feldern in der Ergebnismenge ab. Im Fall von COM_LIST_FIELDS kann das Paket auch eine Fehlermeldung oder ein EOF-Paket enthalten.	Nur nützlich für die Fehlersuche in der Implementierung des CS-Protokolls. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`packets_received_rset_field_meta`	Verbindung	Die Anzahl der mit dem MySQL-Client-Server-Protokoll empfangenen Metadaten-Pakete (Spalteninformationen) der Ergebnismenge	Nur nützlich für die Fehlersuche in der Implementierung des CS-Protokolls. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`bytes_received_rset_row_packet`	Verbindung	Die Gesamtgröße der mit dem MySQL-Client-Server-Protokoll empfangenen Pakete mit den Zeilendaten der Ergebnismenge in Bytes. Das Paket kann auch eine Fehlermeldung oder ein EOF-Paket enthalten. Die Anzahl der Fehlermeldungen und EOF-Pakete können ermittelt werden, indem `rows_fetched_from_server_normal` und `rows_fetched_from_server_ps` von `bytes_received_rset_row_packet` abgezogen werden.	Nur nützlich für die Fehlersuche in der Implementierung des CS-Protokolls. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`packets_received_rset_row`	Verbindung	Die Anzahl der mit dem MySQL-Client-Server-Protokoll empfangenen Pakete mit den Zeilendaten der Ergebnismenge und deren Gesamtgröße in Bytes	Nur nützlich für die Fehlersuche in der Implementierung des CS-Protokolls. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`bytes_received_prepare_response_packet`	Verbindung	Die Gesamtgröße der Pakete für die Initialisierung vorbereiteter Anweisungen (prepared statement init packets), die vom MySQL-Client-Server-Protokoll als OK zurückgegeben werden, in Bytes. Diese Pakete können auch Fehlermeldungen enthalten. Die Größe der Pakete hängt von der MySQL-Version ab: 9 Bytes bei MySQL 4.1 und 12 Bytes ab MySQL 5.0. Es gibt keine zuverlässige Möglichkeit, die Anzahl der aufgetreten Fehler zu ermitteln. Eventuell lässt sich erraten, dass ein Fehler aufgetreten ist, wenn man sich z. B. immer mit MySQL 5.0 oder neuer verbindet und `bytes_received_prepare_response_packet` != `packets_received_prepare_response` * 12. Siehe auch `ps_prepared_never_executed`, `ps_prepared_once_executed`.	Nur nützlich für die Fehlersuche in der Implementierung des CS-Protokolls. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`packets_received_prepare_response`	Verbindung	Die Anzahl der Pakete für die Initialisierung vorbereiteter Anweisungen (prepared statement init packets), die vom MySQL-Client-Server-Protokoll als OK zurückgegeben werden.	Nur nützlich für die Fehlersuche in der Implementierung des CS-Protokolls. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`bytes_received_change_user_packet`	Verbindung	Die Gesamtgröße der mit dem MySQL-Client-Server-Protokoll empfangenen COM_CHANGE_USER-Pakete in Bytes. Ein Paket kann auch eine Fehlermeldung oder ein EOF enthalten.	Nur nützlich für die Fehlersuche in der Implementierung des CS-Protokolls. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`packets_received_change_user`	Verbindung	Die Anzahl der mit dem MySQL-Client-Server-Protokoll empfangenen COM_CHANGE_USER-Pakete	Nur nützlich für die Fehlersuche in der Implementierung des CS-Protokolls. Es ist zu beachten, dass in der Gesamtgröße in Bytes die Größe des Header-Pakets enthalten ist (4 Bytes, siehe Protokoll-Overhead).
`packets_sent_command`	Verbindung	Die Anzahl der Befehle des MySQL-Client-Server-Protokolls, die von PHP an MySQL gesendet wurden. Es gibt keine Möglichkeit herauszufinden, welche spezifischen Befehle gesendet wurden und wie viele davon. Bestenfalls kann damit überprüft werden, ob PHP Befehle an MySQL gesendet hat, um festzustellen, ob die Unterstützung von MySQL in der PHP-Binärdatei deaktiviert werden kann. Es gibt auch keine Möglichkeit, die Anzahl der Fehler zu ermitteln, die beim Senden von Daten an MySQL aufgetreten sind. Der einzige Fehler, der aufgezeichnet wird, ist command_buffer_too_small (siehe unten).	Nur nützlich für die Fehlersuche in der Implementierung des CS-Protokolls.
`bytes_received_real_data_normal`	Verbindung	Die Anzahl der Bytes an Nutzdaten, die der PHP-Client über das Textprotokoll von `mysqlnd` abgerufen hat.	Dies ist die Größe der tatsächlichen Daten, die in den Ergebnismengen enthalten sind, die vom PHP-Client abgerufen wurden und nicht aus vorbereiteten Anweisungen stammen. Zu beachten ist, dass, obwohl eine vollständige Ergebnismenge von `mysqlnd` aus MySQL abgerufen wurde, diese Statistik nur die tatsächlichen Daten zählt, die vom PHP-Client aus `mysqlnd` abgerufen wurden. Ein Beispiel für eine Codesequenz, die den Wert erhöht, lautet wie folgt: $mysqli = new mysqli(); $res = $mysqli->query("SELECT 'abc'"); $res->fetch_assoc(); $res->close(); Jeder Abrufvorgang erhöht den Wert. Die Statistik wird nicht erhöht, wenn die Ergebnismenge auf dem Client nur gepuffert, aber nicht abgerufen wird, wie im folgenden Beispiel: $mysqli = new mysqli(); $res = $mysqli->query("SELECT 'abc'"); $res->close();
`bytes_received_real_data_ps`	Verbindung	Die Anzahl der Bytes an Nutzdaten, die der PHP-Client über das Protokoll für vorbereitete Anweisungen von `mysqlnd` abgerufen hat.	Dies ist die Größe der tatsächlichen Daten, die in den Ergebnismengen enthalten sind, die vom PHP-Client abgerufen wurden und aus vorbereiteten Anweisungen stammen. Der Wert erhöht sich nur dann, wenn die Ergebnismenge anschließend vom PHP-Client gelesen wird. Zu beachten ist, dass, obwohl eine vollständige Ergebnismenge von `mysqlnd` aus MySQL abgerufen wurde, diese Statistik nur die tatsächlichen Daten zählt, die vom PHP-Client aus `mysqlnd` abgerufen wurden. Siehe auch `bytes_received_real_data_normal`.

Ergebnismenge

**Von mysqlnd zurückgegebene Statistiken: Ergebnismenge**
Statistik	Bereich	Beschreibung	Hinweise
`result_set_queries`	Verbindung	Die Anzahl der Abfragen, die eine Ergebnismenge erzeugt haben. Beispiele für Abfragen, die eine Ergebnismenge erzeugen: `SELECT`, `SHOW`. Die Statistik wird nicht erhöht, wenn beim Lesen des Header-Pakets einer Zeile der Ergebnismenge ein Fehler aufgetreten ist.	Dieser Wert kann als indirektes Maß für die Anzahl der von PHP an MySQL gesendeten Anfragen verwendet werden, um z. B. einen Client zu identifizieren, der eine hohe Datenbanklast verursacht.
`non_result_set_queries`	Verbindung	Die Anzahl der Abfragen, die keine Ergebnismenge erzeugt haben. Beispiele für Abfragen, die keine Ergebnismenge erzeugen: `INSERT`, `UPDATE`, `LOAD DATA`. Die Statistik wird nicht erhöht, wenn beim Lesen des Header-Pakets einer Zeile der Ergebnismenge ein Fehler aufgetreten ist.	Dieser Wert kann als indirektes Maß für die Anzahl der von PHP an MySQL gesendeten Anfragen verwendet werden, um z. B. einen Client zu identifizieren, der eine hohe Datenbanklast verursacht.
`no_index_used`	Verbindung	Die Anzahl der Abfragen, die eine Ergebnismenge erzeugt, aber keinen Index verwendet haben (siehe auch die mysqld-Startoption –log-queries-not-using-indexes).	Wenn diese Anfragen gemeldet werden sollen, muss mysqli_report(MYSQLI_REPORT_INDEX) verwendet werden, damit ext/mysqli eine Exception auslöst. Wenn eine Warnung anstelle einer Exception benötigt wird, muss mysqli_report(MYSQLI_REPORT_INDEX ^ MYSQLI_REPORT_STRICT) verwendet werden.
`bad_index_used`	Verbindung	Die Anzahl der Abfragen, die eine Ergebnismenge erzeugt, aber keinen guten Index verwendet haben (siehe auch die mysqld-Startoption –log-slow-queries).	Wenn diese Anfragen gemeldet werden sollen, muss mysqli_report(MYSQLI_REPORT_INDEX) verwendet werden, damit ext/mysqli eine Exception auslöst. Wenn eine Warnung anstelle einer Exception benötigt wird, muss mysqli_report(MYSQLI_REPORT_INDEX ^ MYSQLI_REPORT_STRICT) verwendet werden.
`slow_queries`	Verbindung	SQL-Anweisungen, deren Ausführung länger als `long_query_time` Sekunden dauerte und bei denen mindestens `min_examined_row_limit` Zeilen untersucht werden mussten.	Wird von mysqli_report() nicht gemeldet
`buffered_sets`	Verbindung	Die Anzahl der gepufferten Ergebnismengen, die von normalen Abfragen zurückgegeben wurden. Normal bedeutet ohne vorbereitete Anweisung im Sinne der folgenden Hinweise.	Beispiele für API-Aufrufe, die Ergebnismengen auf dem Client puffern: mysql_query(), mysqli_query(), mysqli_store_result(), mysqli_stmt_get_result(). Durch das Zwischenspreichern der Ergebnismengen auf dem Client wird sichergestellt, dass die Ressourcen des Servers so schnell wie möglich freigegeben werden. Außerdem ist es einfacher, die Ergebnismengen zu durchsuchen. Der Nachteil ist der zusätzliche Speicherbedarf des Clients für die Pufferung der Daten. Es ist zu beachten, dass mysqlnd (im Gegensatz zur MySQL Client Library) das PHP-Speicherlimit einhält, weil es PHP-interne Speicherverwaltungsfunktionen verwendet, um Speicher zuzuweisen. Das ist auch der Grund, warum memory_get_usage() einen höheren Speicherverbrauch meldet, wenn mysqlnd anstelle der MySQL Client Library verwendet wird. Der Speicherbedarf der MySQL Client Library wird von memory_get_usage() überhaupt nicht gemessen, weil die MySQL Client Library keine von der Funktion überwachten PHP-internen Speicherverwaltungsfunktionen verwendet!
`unbuffered_sets`	Verbindung	Die Anzahl der ungepufferten Ergebnismengen, die von normalen Abfragen (ohne vorbereitete Anweisung) zurückgegeben wurden.	Ein Beispiel für API-Aufrufe, die keine Ergebnismengen auf dem Client puffern: mysqli_use_result()
`ps_buffered_sets`	Verbindung	Die Anzahl der gepufferten Ergebnismengen, die von vorbereiteten Anweisungen zurückgegeben wurden. In der Standardeinstellung werden vorbereitete Anweisungen nicht gepuffert.	Ein Beispiel für API-Aufrufe, die Ergebnismengen auf dem Client puffern: `mysqli_stmt_store_result`
`ps_unbuffered_sets`	Verbindung	Die Anzahl der ungepufferten Ergebnismengen, die von vorbereiteten Anweisungen zurückgegeben wurden.	In der Standardeinstellung werden vorbereitete Anweisungen nicht gepuffert.
`flushed_normal_sets`	Verbindung	Die Anzahl der Ergebnismengen normaler Abfragen (ohne vorbereitete Anweisung) mit ungelesenen Daten, die stillschweigend geleert wurden. Die Bereinigung (Flushing) erfolgt nur bei ungepufferten Ergebnismengen.	Ungepufferte Ergebnismengen müssen vollständig abgerufen werden, bevor eine neue Abfrage über die Verbindung ausgeführt werden kann, sonst gibt MySQL einen Fehler aus. Wenn eine Anwendung nicht alle Zeilen aus einer ungepufferten Ergebnismenge abruft, ruft mysqlnd die Ergebnismenge implizit ab, um die die Verbindung freizugeben. Siehe auch `rows_skipped_normal`, `rows_skipped_ps`. Ein paar mögliche Ursachen für einen impliziten Flush: Eine fehlerhafte Client-Anwendung Der Client hat aufgehört, Zeilen abzurufen, weil er gefunden hat, wonach er gesucht hat, aber die Ergebnismenge wurde noch nicht vollständig abgerufen Die Client-Anwendung wurde unerwartet beendet
`flushed_ps_sets`	Verbindung	Die Anzahl der Ergebnismengen vorbereiteter Anweisungen mit ungelesenen Daten, die stillschweigend geleert wurden. Die Bereinigung (Flushing) erfolgt nur bei ungepufferten Ergebnismengen.	Ungepufferte Ergebnismengen müssen vollständig abgerufen werden, bevor eine neue Abfrage über die Verbindung ausgeführt werden kann, sonst gibt MySQL einen Fehler aus. Wenn eine Anwendung nicht alle Zeilen aus einer ungepufferten Ergebnismenge abruft, ruft mysqlnd die Ergebnismenge implizit ab, um die die Verbindung freizugeben. Siehe auch `rows_skipped_normal`, `rows_skipped_ps`. Ein paar mögliche Ursachen für einen impliziten Flush: Eine fehlerhafte Client-Anwendung Der Client hat aufgehört, Zeilen abzurufen, weil er gefunden hat, wonach er gesucht hat, aber die Ergebnismenge wurde noch nicht vollständig abgerufen Die Client-Anwendung wurde unerwartet beendet
`ps_prepared_never_executed`	Verbindung	Die Anzahl der vorbereiteten, aber nie ausgeführten Anweisungen	Vorbereitete Anweisungen belegen Server-Ressourcen. Eine Anweisung sollte nur dann vorbereitet werden, wenn sie auch ausgeführt werden soll.
`ps_prepared_once_executed`	Verbindung	Die Anzahl der vorbereiteten Anweisungen, die nur einmal ausgeführt wurden	Eine der Ideen hinter vorbereiteten Anweisungen ist, dieselbe Abfrage immer wieder auszuführen (mit unterschiedlichen Parametern), sodass ein Teil der Syntaxanalyse und anderer Vorbereitungsarbeiten eingespart werden kann, wenn die Ausführung der Anweisung in separate Vorbereitungs- und Ausführungsphasen aufgeteilt wird. Die Idee ist, eine Anweisung einmal vorzubereiten und die Ergebnisse zwischenzuspeichern, zu cachen, z. B. den Syntaxbaum, der dann bei wiederholter Ausführung einer Anweisung wiederverwendet werden kann. Wenn eine vorbereitete Anweisung nur einmal ausgeführt wird, kann die zweistufige Verarbeitung im Vergleich zu einer normalen Abfrage ineffizient sein, weil die Zwischenspeicherung zusätzliche Arbeit bedeutet und (begrenzte) Server-Ressourcen für die Speicherung der zwischengespeicherten Informationen benötigt werden. Folglich können vorbereitete Anweisungen, die nur einmal ausgeführt werden, zu Leistungseinbußen führen.
`rows_fetched_from_server_normal`, `rows_fetched_from_server_ps`	Verbindung	Die Anzahl der Zeilen der Ergebnismenge, die erfolgreich von MySQL abgerufen wurden, unabhängig davon, ob die Client-Anwendung sie verarbeitet hat oder nicht. Einige der Zeilen wurden möglicherweise nicht von der Client-Anwendung abgerufen, sondern implizit geleert.	Siehe auch `packets_received_rset_row`
`rows_buffered_from_client_normal`, `rows_buffered_from_client_ps`	Verbindung	Die Anzahl der erfolgreich gepufferten Zeilen, die von einer "normalen" Abfrage oder einer vorbereiteten Anweisung stammen. Dies ist die Anzahl der Zeilen, die von MySQL abgerufen und auf dem Client gepuffert wurden. Es ist zu beachten, dass es zwei verschiedene Statistiken gibt: über Zeilen, die gepuffert wurden (der interne Puffer zwischen MySQL und mysqlnd) und über gepufferte Zeilen, die von der Client-Anwendung abgerufen wurden (der interne Puffer zwischen mysqlnd und Client-Anwendung). Wenn die Anzahl der gepufferten Zeilen höher ist als die Anzahl der abgerufenen gepufferten Zeilen, kann das bedeuten, dass die Client-Anwendung Abfragen ausführt, die größere Ergebnismengen verursachen als nötig, was zu Zeilen führt, die vom Client nicht gelesen werden.	Beispiele für Abfragen, die Ergebnisse puffern: mysqli_query(), mysqli_store_result()
`rows_fetched_from_client_normal_buffered`, `rows_fetched_from_client_ps_buffered`	Verbindung	Die Anzahl der Zeilen, die der Client aus einer gepufferten Ergebnismenge abgerufen hat, die durch eine "normale" Abfrage oder eine vorbereitete Anweisung erstellt wurde.
`rows_fetched_from_client_normal_unbuffered`, `rows_fetched_from_client_ps_unbuffered`	Verbindung	Die Anzahl der Zeilen, die der Client aus einer ungepufferten Ergebnismenge abgerufen hat, die durch eine "normale" Abfrage oder eine vorbereitete Anweisung erstellt wurde.
`rows_fetched_from_client_ps_cursor`	Verbindung	Die Anzahl der Zeilen, die der Client von einem durch eine vorbereitete Anweisung erstellten Zeiger (Cursor) abruft
`rows_skipped_normal`, `rows_skipped_ps`	Verbindung	Für zukünftige Verwendung reserviert (wird derzeit nicht unterstützt)
`copy_on_write_saved`, `copy_on_write_performed`	Prozess	Bei mysqlnd zeigen die von den Erweiterungen zurückgegebenen Variablen auf die internen Netzwerk-Ergebnispuffer von mysqlnd. Wenn die Variablen nicht verändert werden, werden die abgerufenen Daten nur einmal im Speicher gehalten. Wenn die Variablen verändert werden, muss mysqlnd ein Copy-on-Write (Kopieren beim Schreiben) durchführen, um die internen Netzwerk-Ergebnispuffer vor Änderungen zu schützen. Bei der MySQL Client Library werden die abgerufenen Daten immer zweimal im Speicher gehalten. Einmal in den internen Puffern der MySQL Client Library und einmal in den Variablen, die von den Erweiterungen zurückgegeben werden. Theoretisch kann mysqlnd bis zu 40% Speicherplatz sparen. Allerdings ist zu beachten, dass die Speichereinsparung nicht mit memory_get_usage() gemessen werden kann.
`explicit_free_result`, `implicit_free_result`	Verbindung, Prozess (nur während der Bereinigung der vorbereiteten Anweisung)	Die Anzahl der freigegebenen Ergebnismengen	Abgesehen von Ergebnismengen, die durch einen init-Befehl erzeugt werden, wird das Freigeben immer als explizit betrachtet, z. B. `mysqli_options(MYSQLI_INIT_COMMAND , ...)`
`proto_text_fetched_null`, `proto_text_fetched_bit`, `proto_text_fetched_tinyintproto_text_fetched_short`, `proto_text_fetched_int24`, `proto_text_fetched_intproto_text_fetched_bigint`, `proto_text_fetched_decimal`, `proto_text_fetched_floatproto_text_fetched_double`, `proto_text_fetched_date`, `proto_text_fetched_yearproto_text_fetched_time`, `proto_text_fetched_datetime`, `proto_text_fetched_timestampproto_text_fetched_string`, `proto_text_fetched_blob`, `proto_text_fetched_enumproto_text_fetched_set`, `proto_text_fetched_geometry`, `proto_text_fetched_other`	Verbindung	Die Anzahl der Spalten eines bestimmten Typs, die aus einer normalen Abfrage abgerufen wurden (MySQL-Textprotokoll)	Zuordnung zwischen C-API/MySQL-Metadatentypen und Statistiknamen: `MYSQL_TYPE_NULL` - proto_text_fetched_null `MYSQL_TYPE_BIT` - proto_text_fetched_bit `MYSQL_TYPE_TINY` - proto_text_fetched_tinyint `MYSQL_TYPE_SHORT` - proto_text_fetched_short `MYSQL_TYPE_INT24` - proto_text_fetched_int24 `MYSQL_TYPE_LONG` - proto_text_fetched_int `MYSQL_TYPE_LONGLONG` - proto_text_fetched_bigint `MYSQL_TYPE_DECIMAL`, `MYSQL_TYPE_NEWDECIMAL` - proto_text_fetched_decimal `MYSQL_TYPE_FLOAT` - proto_text_fetched_float `MYSQL_TYPE_DOUBLE` - proto_text_fetched_double `MYSQL_TYPE_DATE`, `MYSQL_TYPE_NEWDATE` - proto_text_fetched_date `MYSQL_TYPE_YEAR` - proto_text_fetched_year `MYSQL_TYPE_TIME` - proto_text_fetched_time `MYSQL_TYPE_DATETIME` - proto_text_fetched_datetime `MYSQL_TYPE_TIMESTAMP` - proto_text_fetched_timestamp `MYSQL_TYPE_STRING`, `MYSQL_TYPE_VARSTRING`, `MYSQL_TYPE_VARCHAR` - proto_text_fetched_string `MYSQL_TYPE_TINY_BLOB`, `MYSQL_TYPE_MEDIUM_BLOB`, `MYSQL_TYPE_LONG_BLOB`, `MYSQL_TYPE_BLOB` - proto_text_fetched_blob `MYSQL_TYPE_ENUM` - proto_text_fetched_enum `MYSQL_TYPE_SET` - proto_text_fetched_set `MYSQL_TYPE_GEOMETRY` - proto_text_fetched_geometry Alle hier nicht aufgeführten `MYSQL_TYPE_` (es sollte keine geben) - proto_text_fetched_other Es ist zu beachten, dass die MYSQL_-Typ-Konstanten nicht in jeder MySQL-Version mit denselben SQL-Spaltentypen verknüpft sein müssen.
`proto_binary_fetched_null`, `proto_binary_fetched_bit`, `proto_binary_fetched_tinyintproto_binary_fetched_short`, `proto_binary_fetched_int24`, `proto_binary_fetched_int`, `proto_binary_fetched_bigint`, `proto_binary_fetched_decimal`, `proto_binary_fetched_float`, `proto_binary_fetched_double`, `proto_binary_fetched_date`, `proto_binary_fetched_year`, `proto_binary_fetched_time`, `proto_binary_fetched_datetime`, `proto_binary_fetched_timestamp`, `proto_binary_fetched_string`, `proto_binary_fetched_blob`, `proto_binary_fetched_enum`, `proto_binary_fetched_set`, `proto_binary_fetched_geometry`, `proto_binary_fetched_other`	Verbindung	Die Anzahl der Spalten eines bestimmten Typs, die aus einer vorbereiteten Anweisung abgerufen wurden (MySQL-Binärprotokoll)	Für die Zuordnung der Typen siehe die Beschreibung von `proto_text_*` im vorhergehenden Punkt.

**Von mysqlnd zurückgegebene Statistiken: Verbindung**
Statistik	Bereich	Beschreibung	Hinweise
`connect_success`, `connect_failure`	Verbindung	Die Anzahl der erfolgreichen/fehlgeschlagenen Verbindungsversuche	Wiederverwendete Verbindungen und alle anderen Arten von Verbindungen sind darin enthalten.
`reconnect`	Prozess	Die Anzahl der (real_)connect-Versuche an einem bereits geöffneten Verbindungshandle	Die Codesequenz `$link = new mysqli(...); $link->real_connect(...)` führt zu einem Wiederaufbau einer Verbindung. `$link = new mysqli(...); $link->connect(...)` hingegen nicht, weil `$link->connect(...)` die bestehende Verbindung explizit schließt, bevor eine neue Verbindung aufgebaut wird.
`pconnect_success`	Verbindung	Die Anzahl der erfolgreichen Versuche, eine persistente (dauerhafte) Verbindung herzustellen	Es ist zu beachten, dass `connect_success` die Summe der erfolgreichen persistenten und nicht-persistenten Verbindungsversuche enthält. Die Anzahl der erfolgreichen nicht-persistenten Verbindungsversuche ist `connect_success` - `pconnect_success`.
`active_connections`	Verbindung	Die Anzahl der aktiven Verbindungen (persistent und nicht-persistent)
`active_persistent_connections`	Verbindung	Die Anzahl der aktiven persistenten Verbindungen	Die Anzahl der nicht-persistenten Verbindungen ist `active_connections` - `active_persistent_connections`.
`explicit_close`	Verbindung	Die Anzahl der explizit geschlossenen Verbindungen (nur ext/mysqli)	Beispiele für Codeschnipsel, die zu einem expliziten Schließen führen: $link = new mysqli(...); $link->close(...) $link = new mysqli(...); $link->connect(...)
`implicit_close`	Verbindung	Die Anzahl der implizit geschlossenen Verbindungen (nur ext/mysqli)	Beispiele für Codeschnipsel, die zu einem impliziten Schließen führen: `$link = new mysqli(...); $link->real_connect(...)` `unset($link)` persistente Verbindung: eine gepoolte Verbindung wurde mit real_connect erstellt und es können unbekannte Optionen gesetzt sein - implizites Schließen, um die Rückgabe einer Verbindung mit unbekannten Optionen zu vermeiden persistente Verbindung: ping/change_user schlägt fehl und ext/mysqli schließt die Verbindung am Ende der Skriptausführung: Schließen der Verbindungen, die noch nicht vom Benutzer geschlossen wurden
`disconnect_close`	Verbindung	Die Anzahl der fehlgeschlagenen Verbindungen, die der C-API-Aufruf mysql_real_connect() beim Versuch, eine Verbindung aufzubauen, meldet	Diese Statistik heißt `disconnect_close`, weil das an den C-API-Aufruf übergebene Verbindungshandle geschlossen wird.
`in_middle_of_command_close`	Prozess	Eine Verbindung wurde mitten in der Ausführung eines Befehls geschlossen (noch nicht abgerufene Ergebnismengen, nachdem eine Abfrage gesendet und bevor eine Antwort abgerufen wurde, während Daten abgerufen wurden, während Daten mit LOAD DATA übertragen wurden)	Sofern keine asynchronen Abfragen verwendet werden, sollte dies nur passieren, wenn ein Skript unerwartet gestoppt wird und PHP die Verbindungen automatisch schließt.
`init_command_executed_count`	Verbindung	Die Anzahl der ausgeführten init-Befehle, zum Beispiel `mysqli_options(MYSQLI_INIT_COMMAND , ...)`.	Die Anzahl der erfolgreichen Ausführungen ist `init_command_executed_count` - `init_command_failed_count`.
`init_command_failed_count`	Verbindung	Die Anzahl der fehlgeschlagenen init-Befehle

**Von mysqlnd zurückgegebene Statistiken: COM_*-Befehl**
Statistik	Bereich	Beschreibung	Hinweise
`com_quit`, `com_init_db`, `com_query`, `com_field_list`, `com_create_db`, `com_drop_db`, `com_refresh`, `com_shutdown`, `com_statistics`, `com_process_info`, `com_connect`, `com_process_kill`, `com_debug`, `com_ping`, `com_time`, `com_delayed_insert`, `com_change_user`, `com_binlog_dump`, `com_table_dump`, `com_connect_out`, `com_register_slave`, `com_stmt_prepare`, `com_stmt_execute`, `com_stmt_send_long_data`, `com_stmt_close`, `com_stmt_reset`, `com_stmt_set_option`, `com_stmt_fetch`, `com_daemon`	Verbindung	Die Anzahl der Versuche, einen bestimmten COM_*-Befehl von PHP an MySQL zu senden	Die Statistik wird erhöht, nachdem die Zeile geprüft wurde und unmittelbar bevor das entsprechende MySQL-Client-Server-Protokoll-Paket gesendet wird. Die Statistik wird nicht nach unten korrigiert, wenn mysqlnd das Paket nicht über die Leitung senden kann. Im Falle eines Fehlers gibt mysqlnd die PHP-Warnung Error while sending %s packet. PID=%d. aus. Beispiele für die Verwendung: Überprüfen, ob PHP bestimmte Befehle an MySQL sendet, zum Beispiel, ob ein Client `COM_PROCESS_KILL` sendet Berechnen der durchschnittlichen Anzahl der ausgeführten vorbereiteten Anweisungen durch Vergleich von `COM_EXECUTE` und `COM_PREPARE` Überprüfen, ob PHP nicht-vorbereitete SQL-Anweisungen ausgeführt hat, indem kontrolliert wird, ob `COM_QUERY` Null ist Erkennen von PHP-Skripten, die eine zu große Anzahl von SQL-Anweisungen ausführen, indem `COM_QUERY` und `COM_EXECUTE` überprüft werden

Sonstige

**Von mysqlnd zurückgegebene Statistiken: Sonstige**
Statistik	Bereich	Beschreibung	Hinweise
`explicit_stmt_close`, `implicit_stmt_close`	Prozess	Die Anzahl der abgeschlossenen vorbereiteten Anweisungen	Ein Abschluss gilt immer als explizit, außer wenn die Vorbereitung fehlgeschlagen ist.
`mem_emalloc_count`, `mem_emalloc_ammount`, `mem_ecalloc_count`, `mem_ecalloc_ammount`, `mem_erealloc_count`, `mem_erealloc_ammount`, `mem_efree_count`, `mem_malloc_count`, `mem_malloc_ammount`, `mem_calloc_count`, `mem_calloc_ammount`, `mem_realloc_count`, `mem_realloc_ammount`, `mem_free_count`	Prozess	Die Anzahl der Aufrufe bezüglich Speicherverwaltung	Nur für die Entwicklung
`command_buffer_too_small`	Verbindung	Die Anzahl der Erweiterungen des Netzwerk-Befehlspuffers, wenn PHP einen Befehl an MySQL sendet	mysqlnd weist jeder Verbindung einen internen Befehls-/Netzwerkpuffer von `mysqlnd.net_cmd_buffer_size` (`php.ini`) Bytes zu. Wenn ein Befehl des MySQL-Client-Server-Protokolls, z. B. `COM_QUERY` (normale Abfrage), nicht in den Puffer passt, vergrößert mysqlnd den Puffer auf die Größe, die zum Senden des Befehls erforderlich ist. Jedes Mal, wenn der Puffer für eine Verbindung vergrößert wird, wird `command_buffer_too_small` um eins erhöht. Wenn mysqlnd den Puffer bei fast jeder Verbindung über seine anfängliche Größe von `mysqlnd.net_cmd_buffer_size` (`php.ini`) Bytes hinaus vergrößern muss, sollte in Erwägung gezogen werden, die Standardgröße zu erhöhen, um Neuzuweisungen zu vermeiden. Die voreingestellte Puffergröße beträgt 4096 Bytes, was der kleinstmögliche Wert ist. Dieser Wert kann entweder in der `php.ini` durch die Einstellung `mysqlnd.net_cmd_buffer_size` geändert werden oder durch `mysqli_options(MYSQLI_OPT_NET_CMD_BUFFER_SIZE, int size)`.
`connection_reused`