統計情報
統計情報を使う
MySQL Native Driver は、クライアントとサーバー間の通信に関する統計情報を収集する機能をサポートしています。収集できる統計情報は主に2つのタイプに分けられます。
-
クライアントの統計情報
-
接続の統計情報
mysqli 拡張モジュールを使っている場合、これらの統計情報は以下の2つのAPIを呼び出すことで取得できます。
注意:
MySQL Native Driver を使っているすべての拡張モジュールが統計情報を収集します。たとえば、
ext/mysqlやext/mysqliを MySQL Native Driver を使ってコンパイルし、ext/mysqlやext/mysqliの関数を呼び出すと、収集される統計情報の値が変わります。MySQL Native Driver を使ってコンパイルされた MySQL 拡張モジュールの呼び出しが、どの程度統計情報に影響を与えるかはわかりません。PDO MySQL Driver やext/mysqlやext/mysqliを、オプションで MySQL Native Driver を使うように設定することができます。こうすると、すべての拡張モジュールで統計情報を変化させることができます。
クライアントの統計情報にアクセスする
クライアントの統計情報にアクセスするには、mysqli_get_client_stats() 関数を呼び出す必要があります。この関数を呼び出すのに引数は必要ありません。
この関数は、統計情報の名前をキーとして対応するデータを値とする連想配列を返します。
クライアントの統計情報は phpinfo() 関数を呼び出してもアクセスできます。
接続の統計情報にアクセスする
接続の統計情報にアクセスするには mysqli_get_connection_stats() 関数を使います。この関数は接続ハンドルを引数にとります。
この関数は、統計情報の名前をキーとして対応するデータを値とする連想配列を返します。
結果セットをバッファリングさせるか否か
結果セットはバッファリングさせることもできますし、しないこともできます。デフォルトの設定では、ext/mysql と ext/mysqli は通常の (プリペアドステートメントでない) クエリの場合結果セットをバッファリングします。バッファリングされた結果セットはクライアント側でキャッシュされます。クエリが実行された後、すべての結果がMySQLサーバーから取得され、クライアント側でキャッシュに保存されます。結果セットをバッファリングすることの大きな利点は、一度クライアントが結果を取得すると、サーバーがすべての結果セットに割り当てられたリソースを開放できることです。
一方、結果セットをバッファリングしない場合、結果セットはサーバー側にバッファリングするよりも長く残ります。仮にクライアント側でのメモリ使用量を削減したいが、サーバー側の負荷が高くなっても構わない場合、結果セットをバッファリングしないようにします。仮にサーバーの負荷が高く、バッファリングしていない結果セットの量がサーバー側で多いことが分かっている場合、その負荷をクライアント側に移すことを検討すべきです。クライアントは通常の場合サーバーよりも分散しやすいからです。ここでいう 負荷
とはメモリバッファに対するものだけでなく、サーバーが結果セットを開放する前に他のリソース、たとえばファイルハンドルやスレッドを開きっぱなしにする必要があることも指しています。
プリペアドステートメントはデフォルトでは結果セットをバッファリングしません。しかし、mysqli_stmt_store_result() 関数を使えば、結果セットのバッファリングを有効にすることができます。
MySQL Native Driver が返す統計情報
以下の表で、mysqli_get_client_stats(), mysqli_get_connection_stats() 関数が返す統計情報のリストを示します。
| 統計情報 | 統計のカテゴリ | 説明 | 注意点 |
|---|---|---|---|
bytes_sent |
Connection | PHP から MySQLサーバーに送信されたバイト数 | 圧縮プロトコルの効率をチェックするのに使えます |
bytes_received |
Connection | MySQLサーバーから受け取ったバイト数 | 同上 |
packets_sent |
Connection | MySQL のクライアントサーバープロトコルにおいて送信されたパケット数 | クライアントサーバープロトコルの実装をデバッグするのに使われます |
packets_received |
Connection | MySQL のクライアントサーバープロトコルにおいて受信したパケット数 | 同上 |
protocol_overhead_in |
Connection | MySQL のクライアントサーバープロトコルの受信側の通信にかかるオーバーヘッドをバイト単位で示します。現状はパケットヘッダ(4バイト)のみをオーバーヘッドと看做しています。 protocol_overhead_in = packets_received * 4で表されます。 | 同上 |
protocol_overhead_out |
Connection | MySQL のクライアントサーバープロトコルの受信側の通信にかかるオーバーヘッドをバイト単位で示します。現状はパケットヘッダ(4バイト)のみをオーバーヘッドと看做しています。 protocol_overhead_out = packets_sent * 4で表されます。 | 同上 |
bytes_received_ok_packet |
Connection | MySQL のクライアントサーバープロトコルにおけるOKパケットの受信量の合計をバイト単位で示します。 OKパケットはステータスメッセージも含むことができます。ステータスメッセージの長さは変化しうるため、OKパケットのサイズは固定ではありません。 | クライアントサーバープロトコルの実装をデバッグするのに使われます。受信する合計バイト数には、パケットヘッダ(4バイト, protocol_overhead_in や protocol_overhead_out を参照) のサイズも含まれていることに注意してください |
packets_received_ok |
Connection | MySQL のクライアントサーバープロトコルにおけるOKパケットを受信した数です。 | 同上 |
bytes_received_eof_packet |
Connection | MySQL のクライアントサーバープロトコルにおけるEOFパケットを受信量の合計をバイト単位で示します。EOFパケットはサーバーのバージョンによってサイズが変わります。また、EOFパケットはエラーメッセージも伝えることができます。 | 同上 |
packets_received_eof |
Connection | MySQL のクライアントサーバープロトコルにおけるEOFパケットの数を示します。EOFパケットの数は、PHPが期待するパケットを受け取らなかった場合であっても増加します。これは他のパケット数を示す統計情報と同じです。PHPが期待しないパケットの例は、エラーメッセージが挙げられます。 | 同上 |
bytes_received_rset_header_packet |
Connection | MySQL のクライアントサーバープロトコルにおける結果セットにあるヘッダパケットの合計サイズをバイト単位で示します。パケットのサイズはペイロード(LOAD LOCAL INFILE, INSERT, UPDATE, SELECT, エラーメッセージ)に応じて変わります。 |
同上 |
packets_received_rset_header |
Connection | MySQL のクライアントサーバープロトコルにおける結果セットにあるヘッダパケットの数を示します | 同上 |
bytes_received_rset_field_meta_packet |
Connection | MySQL のクライアントサーバープロトコルにおける結果セットにあるメタデータ(カラム情報) の合計サイズをバイト単位で示します。もちろん、メタデータのサイズは結果セットにあるカラムによって変わります。このパケットはペイロードが COM_LIST_FIELDS の場合(訳注：テーブルのカラム情報を得るためのMySQLプロトコル http://dev.mysql.com/doc/internals/en/text-protocol.html#com-field-list)の場合は、エラーメッセージかEOFパケットを返す可能性があります。 | 同上 |
packets_received_rset_field_meta |
Connection | MySQL のクライアントサーバープロトコルにおける結果セットにあるメタデータ(カラム情報) のパケット数を示します。 | 同上 |
bytes_received_rset_row_packet |
Connection | MySQL のクライアントサーバープロトコルにおける結果セットにある行情報パケットの合計サイズをバイト単位で示します。このパケットはエラー情報またはEOFパケットを送信する場合もあります。
bytes_received_rset_row_packet の数から、rows_fetched_from_server_normal と rows_fetched_from_server_ps の値を引くことによって、エラー数やEOFパケットの数を割り出すことができます。 |
同上 |
packets_received_rset_row |
Connection | MySQL のクライアントサーバープロトコルの結果セット行データパケットと、それらの合計サイズをバイト単位で示します。 | 同上 |
bytes_received_prepare_response_packet |
Connection | MySQL のクライアントサーバープロトコルにおける、プリペアドステートメント初期化パケット(prepared statement init packets) が OK を返した合計サイズをバイト単位で示します。このパケットはエラーを送信する可能性もあります。このパケットのサイズは MySQL のバージョンによって変わります。: MySQL 4.1 では 9バイト、 MySQ 5.0 以降は 12 byte です。エラーが起きた回数を安全に知る方法はありません。たとえば、MySQL 5.0 以降の MySQL に常に接続している場合は、bytes_received_prepare_response_packet != packets_received_prepare_response * 12 の場合にエラーが起きていると推定できるかもしれません。ps_prepared_never_executed や ps_prepared_once_executed も参照ください。 |
同上 |
packets_received_prepare_response |
Connection | MySQL のクライアントサーバープロトコルにおける、プリペアドステートメント初期化パケット(prepared statement init packets) が OK を返した数 | 同上 |
bytes_received_change_user_packet |
Connection | MySQL のクライアントサーバープロトコルにおける、COM_CHANGE_USER パケットの合計サイズをバイト単位で示します。このパケットはエラーやEOFパケットを送信する可能性もあります。 | 同上 |
packets_received_change_user |
Connection | MySQL のクライアントサーバープロトコルにおける、COM_CHANGE_USER パケットの数 | 同上 |
packets_sent_command |
Connection | PHP から MySQL に送信されたMySQL クライアントサーバープロトコルコマンドの合計数。特定のどのコマンドが送信されたか、そしてそれらのうちどのくらいが実際に送信されたかを知る方法はありません。この統計値は、PHPバイナリで MySQLのサポートを無効にすることを確かめる手がかりを知るために、PHP がコマンドを送信しているかどうかを知る手段として使えるくらいです。また、データを MySQL に送信している間にエラーが起きた回数を知る方法もありません。記録されるエラーは command_buffer_too_small (後述) の値くらいです。 | MySQL のクライアントサーバープロトコルのデバッグする用途だけに役立ちます。 |
bytes_received_real_data_normal |
Connection | PHP クライアントが mysqlnd からテキストプロトコル経由で受け取ったペイロードの合計バイト数。 |
これは、プリペアドステートメントではないクエリから生成され、PHPクライアントが取得した結果セットに含まれる実際のデータサイズです。完全な結果セットは mysqlnd が MySQL から取得しますが、この統計値は PHP クライアントが mysqlnd から実際に取得した実際のデータのみを数えていることに注意してください。この統計値を増やすコードの例は以下のようになります:
$mysqli = new mysqli();
$res = $mysqli->query("SELECT 'abc'");
$res->fetch_assoc();
$res->close();
毎回取得(fetch)操作をするたびにこの値が増加します。 この統計値は、結果セットがクライアント上でバッファリングされただけで、実際に取得されていない場合は変化しません。たとえば、次のようなコードの場合です:
$mysqli = new mysqli();
$res = $mysqli->query("SELECT 'abc'");
$res->close();
|
bytes_received_real_data_ps |
Connection | PHP クライアントが mysqlnd からプリペアドステートメントプロトコル経由で受け取ったペイロードの合計バイト数。 |
これは、プリペアドステートメントプロトコルを使ってから生成され、PHPクライアントが取得した結果セットに含まれる実際のデータサイズです。この値は、PHPクライアントが読み取らなければ変化しません。完全な結果セットは mysqlnd が MySQL から取得しますが、この統計値は PHP クライアントが mysqlnd から実際に取得した実際のデータのみを数えていることに注意してください。bytes_received_real_data_normal も参照ください。 |
Result Set
| 統計情報 | 統計のカテゴリ | 説明 | 注意点 |
|---|---|---|---|
result_set_queries |
Connection | 結果セットを生成したクエリの数。結果セットを生成するクエリの例: SELECT,
SHOW. 結果セットのヘッダパケットを読み取っている間にエラーが発生した場合、この統計値はインクリメントされません |
たとえば、データベースに高い負荷をかけているクライアントを特定する目的で、PHP が MySQL に送信したクエリの数を間接的に測るのに使えます。 |
non_result_set_queries |
Connection | 結果セットを生成しなかったクエリの数。結果セットを生成しないクエリの例:INSERT, UPDATE, LOAD DATA。結果セットのヘッダパケットを読み取っている間にエラーが発生した場合、この統計値はインクリメントされません。 |
同上 |
no_index_used |
Connection | 結果セットを生成したが、インデックスを使わなかったクエリの数 (mysqld の起動オプション -log-queries-not-using-indexes も参照ください) こうしたクエリを記録したい場合、mysqli_report(MYSQLI_REPORT_INDEX) を使って ext/mysqli に例外をスローさせることができます。例外ではなく警告にとどめたい場合は、mysqli_report(MYSQLI_REPORT_INDEX ^ MYSQLI_REPORT_STRICT) を使ってください。 | |
bad_index_used |
Connection | 結果セットを生成したが、良いインデックスを使わなかったクエリの数 (mysqld の起動オプション -log-slow-queries も参照ください) | こうしたクエリを記録したい場合、mysqli_report(MYSQLI_REPORT_INDEX) を使って ext/mysqli に例外をスローさせることができます。例外ではなく警告にとどめたい場合は、mysqli_report(MYSQLI_REPORT_INDEX ^ MYSQLI_REPORT_STRICT) を使ってください。 |
slow_queries |
Connection | 実行に long_query_time 秒以上かかり、少なくとも min_examined_row_limit 行以上調べる必要があるSQL |
mysqli_report()関数では記録できません |
buffered_sets |
Connection | 通常のクエリで返された結果セットのうち、バッファリングされたものの数。 通常のというのは、右の「注意点」で述べている プリペアドステートメントのことではありません |
結果セットをクライアント側にバッファリングするAPI呼び出しの例: mysql_query(), mysqli_query(), mysqli_store_result(), mysqli_stmt_get_result() 結果セットをクライアント側にバッファリングすると、サーバー側のリソースが迅速に解放され、結果セットを走査しやすくなります。欠点としては、クライアント側のメモリ消費が、バッファリングする分だけ増えてしまうということです。mysqlnd は、PHP の内部的なメモリ管理関数を使っているため、(MySQL Client Library とは異なり) PHP 側の memory_limit の設定を尊重することに注意してください。同じ理由で memory_get_usage() 関数の実行結果は、MySQL Client Library と比べて高いメモリ使用量を報告します。memory_get_usage() 関数は MySQL Client Library のメモリ使用量を全く計測しません。なぜなら、MySQL Client Library は この関数が監視する PHP の内部メモリ管理関数を使用していないからです！ |
unbuffered_sets |
Connection | 通常の(プリペアドステートメントではない) クエリによって返された、バッファリングされていない結果セットの数 | クライアント側で結果セットがバッファリングされないAPI呼び出しの例: mysqli_use_result() |
ps_buffered_sets |
Connection | プリペアドステートメントによって返される、バッファリングされた結果セットの数。デフォルトでは、プリペアドステートメントはバッファリングされません。 | クライアント側で結果セットがバッファリングされるAPI呼び出しの例:
mysqli_stmt_store_result |
ps_unbuffered_sets |
Connection | プリペアドステートメントによって返される、バッファリングされない結果セットの数。 | デフォルトでは、プリペアドステートメントはバッファリングされません。 |
flushed_normal_sets |
Connection | 通常の(プリペアドステートメントではない) クエリから返された、クライアントが読み取っていないため黙ってフラッシュされたデータが残っている結果セットの数。フラッシュはバッファリングされていない結果セットの場合だけ起こります。 |
バッファリングされていない結果セットは、新しいクエリが実行される前に完全に取得されなければなりません。そうでない場合、MySQL はエラーを生成します。アプリケーションがバッファリングされていない結果セットからすべての行を取得していない場合、mysqlnd は行をクリアするため暗黙のうちに結果セットをフラッシュします。rows_skipped_normal や、rows_skipped_ps も参照ください。暗黙のフラッシュが起こりうる原因を以下に示します:
|
flushed_ps_sets |
Connection | プリペアドステートメントのクエリから返された、クライアントが読み取っていないため黙ってフラッシュされたデータが残っている結果セットの数。フラッシュはバッファリングされていない結果セットの場合だけ起こります。 | 同上 |
ps_prepared_never_executed |
Connection | 準備(prepare)されたが、決して実行されないステートメントの数 | プリペアドステートメントはサーバーのリソースを占有します。実行する予定がない場合、ステートメントを準備すべきではありません。 |
ps_prepared_once_executed |
Connection | 一度だけ実行されたプリペアドステートメントの数 |
プリペアドステートメントの背後にあるアイディアのうちのひとつは、同じクエリは繰り返し繰り返し(異なるパラメーターで)実行されるんだから、ステートメントの実行が準備と実行に分かれていれば、クエリのパースやほかの準備処理はキャッシュできる、というものです。 このアイディアは準備を一度行い、その結果を キャッシュします。たとえば解析ツリーを複数のステートメントの実行時に再利用するのです。プリペアドステートメントが一度だけしか実行されない場合、二段階に処理が分かれていることは 通常のクエリに比べて非効率かもしれません。なぜなら、すべてのキャッシュは余計なものであり、その情報を保持するためにサーバーは(限られた)リソースを消費しているからです。結果的に、一度しか実行されていないプリペアドステートメントはパフォーマンスを害する原因になる可能性があります。 |
rows_fetched_from_server_normal,
rows_fetched_from_server_ps |
Connection | クライアントが消費していたかいないかに関わらず、MySQLから取得に成功した結果セット行の合計数。行によっては、クライアントアプリケーションは取得しないため暗黙のうちにフラッシュされている場合があります。 | packets_received_rset_row も参照ください |
rows_buffered_from_client_normal,
rows_buffered_from_client_ps |
Connection | 通常のクエリ、またはプリペアドステートメントから生成された、バッファリングに成功した行の合計数。これは MySQL から取得され、クライアントにバッファリングされた行の数です。バッファリングに成功した行については、ふたつの全く別な統計値があることに注意してください。(MySQL から mysqlnd の内部バッファに)バッファリングされた行の数と、(mysqlnd の内部バッファからクライアントアプリケーションへ)取得され、バッファリングされた行の数です。バッファリングされた行数が、取得されてバッファリングされた行より多い場合、クライアントアプリケーションが必要以上に大きな結果セットを生成しているため、クライアントが読み取らない行ができてしまっている可能性があります。 | 結果をバッファリングするクエリの例: mysqli_query(), mysqli_store_result() |
rows_fetched_from_client_normal_buffered,
rows_fetched_from_client_ps_buffered |
Connection | バッファリングされた結果セットからクライアントによって取得された行の合計数。この結果セットは通常のクエリとプリペアドステートメントの両方から生成されたものです。 | |
rows_fetched_from_client_normal_unbuffered,
rows_fetched_from_client_ps_unbuffered |
Connection | バッファリングされて「いない」結果セットからクライアントによって取得された行の合計数。この結果セットは通常のクエリとプリペアドステートメントの両方から生成されたものです。 | |
rows_fetched_from_client_ps_cursor |
Connection | プリペアドステートメントによって生成されたカーソルから、クライアントが取得した行の合計数 | |
rows_skipped_normal,
rows_skipped_ps |
Connection | 将来のために予約されています(今のところサポートされていません) | |
copy_on_write_saved,
copy_on_write_performed |
Process | mysqlnd では、拡張モジュールから返された値は mysqlnd 内部にある通信結果のバッファを指しています。開発者が値を変更しなければ、取得されたデータは一度だけメモリに保持されます。値を変更した場合、mysqlnd は 内部にある通信結果のバッファを変更から保護するために コピーオンライト を実行しなければなりません。MySQL Client Library を使うと、取得したデータを二度メモリに保持します。MySQL Client Library の内部バッファと変数の値が拡張モジュールによって返されるのです。理論上、mysqlnd は40%のメモリを節約できます。しかし、メモリに保持されている量は memory_get_usage()関数では計測できないことに注意してください。 | |
explicit_free_result,
implicit_free_result |
Connection, Process (プリペアドステートメントのクリーンアップ時のみ) | 解放された結果セットの合計数 | ここでいう「解放」とは明示的なもので、初期化コマンドで生成された結果セットを除きます。たとえば 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 |
Connection | 通常のクエリ(MySQL テキストプロトコル) から取得したあるタイプのカラムの合計数 | C API/ MySQL のメタデータと 統計の名前の対応:
MYSQL_*-type 定数は、 MySQL の各バージョンの同じSQLカラムタイプと結びついているとは限らないことに注意してください。 |
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 |
Connection | プリペアドステートメント(MySQL バイナリプロトコル) から取得したあるタイプのカラムの合計数 | カラムタイプと統計の名前の対応は、上の proto_text_* を参照ください |
| 統計情報 | 統計のカテゴリ | 説明 | 注意点 |
|---|---|---|---|
connect_success, connect_failure |
Connection | 接続を試みた結果が 成功 / 失敗 した回数の合計 | 再利用された接続や、他の種類の接続もすべて含みます |
reconnect |
Process | 既に開かれている接続ハンドルに対して(mysqli_real_connectを使って)行われた再接続の合計回数 | 次のコードは、再接続を行います。$link = new mysqli(...);$link->real_connect(...) しかし、次のコードは再接続を行いません。$link = new mysqli(...); $link->connect(...) なぜなら、このコードは新しい接続が確立される前に明示的に既存の接続を閉じるからです。 |
pconnect_success |
Connection | 持続的接続を試みて成功した合計回数 | connect_success は、持続的接続と通常の接続の両方の成功数を合計している点に注意してください。通常の接続の成功数は、connect_success - pconnect_success で求められます。 |
active_connections |
Connection | アクティブな持続的接続と通常の接続の合計値 | |
active_persistent_connections |
Connection | アクティブな持続的接続の合計値 | アクティブな通常の接続の合計値は、active_connections - active_persistent_connections で求められます。 |
explicit_close |
Connection | 明示的に閉じられた接続の合計数(ext/mysqli 限定). | 明示的に接続を閉じるコードの例 :
$link = new mysqli(...); $link->close(...) $link = new mysqli(...); $link->connect(...) |
implicit_close |
Connection | 暗黙的に閉じられた接続の合計数(ext/mysqli 限定). | 暗黙的に接続を閉じるコードの例 :
|
disconnect_close |
Connection | 接続を試み、C API のmysql_real_connect() を呼び出した後に失敗した回数 | C API の呼び出しの際に渡された接続ハンドルを閉じるため、disconnect_close と呼ばれています。 |
in_middle_of_command_close |
Process | コマンドの実行中(クエリを送信し、応答を受け取る前に残っていた結果セットが取得されなかったり、データを取得中だったり、LOAD DATA コマンドのデータを送信中だったりした場合)に閉じられた接続 | 非同期クエリを使っていない場合、コマンド実行中に接続が閉じられるのは、PHPスクリプトが予期しない箇所で終了し、PHPが接続を閉じた場合だけのはずです。 |
init_command_executed_count |
Connection | 初期化コマンドが実行された合計回数。たとえば、以下のようなコードが実行された回数です。
mysqli_options(MYSQLI_INIT_COMMAND , ...) |
初期化コマンドが成功した回数は init_command_executed_count - init_command_failed_count で求められます。 |
init_command_failed_count |
Connection | 初期化コマンドが失敗した回数 |
| 統計情報 | 統計のカテゴリ | 説明 | 注意点 |
|---|---|---|---|
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 |
Connection | PHP から MySQL へ、特定の COM_* コマンドを送信しようとした合計回数 |
これらの統計値は、コマンドをチェックした後、対応する MySQLクライアントサーバープロトコルのパケットが送信される前にインクリメントされます。mysqlnd がパケットの送信に失敗したとしても、統計情報は減りません。パケットの送信にした場合、PHP は 使い方の例:
|
その他
| 統計情報 | 統計のカテゴリ | 説明 | 注意点 |
|---|---|---|---|
explicit_stmt_close,
implicit_stmt_close |
プロセス | プリペアドステートメントが閉じられた合計回数 | プリペアドステートメントは、常に明示的に閉じられるものとみなされます。ただし、prepare に失敗した場合を除きます。 |
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 |
Process | メモリ管理に関する関数コールの回数 | 開発者だけが使うものです。 |
command_buffer_too_small |
データベース接続 | PHP が MySQL にコマンドを送信する際、コマンドバッファの大きさが拡張された回数 |
mysqlnd は、内部的に
mysqlnd が ほぼすべての接続で デフォルトの
デフォルトのバッファサイズは4096バイトです。これは設定可能な最小値です。このデフォルト値は php.ini の |
connection_reused |
add a note
