CakeFest 2024: The Official CakePHP Conference

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_tinyint proto_text_fetched_short, proto_text_fetched_int24, proto_text_fetched_int proto_text_fetched_bigint, proto_text_fetched_decimal, proto_text_fetched_float proto_text_fetched_double, proto_text_fetched_date, proto_text_fetched_year proto_text_fetched_time, proto_text_fetched_datetime, proto_text_fetched_timestamp proto_text_fetched_string, proto_text_fetched_blob, proto_text_fetched_enum proto_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_tinyint proto_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      
add a note

User Contributed Notes

There are no user contributed notes for this page.
To Top