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 auchext/mysqli
mit dem MySQL Native Driver kompiliert werden, verändern sowohl die Funktionsaufrufe vonext/mysql
als auch vonext/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
undext/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.
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
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
normalenAbfragen zurückgegeben wurden. Normalbedeutet ohne vorbereitete Anweisungim 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:
|
|
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:
|
|
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 normalenAbfrage 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:
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. |
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:
|
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 |
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 Beispiele für die Verwendung:
|
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
Wenn mysqlnd den Puffer bei fast jeder Verbindung über seine
anfängliche Größe von
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
|
connection_reused |