mysql サーバーとクライアント プロトコルを見ると、 Ok_Packet に「影響を受ける行」と「last-insert-id」の 2 つの列があります。
Ok_packet は、クライアントから送信されたコマンドの応答としてサーバーからクライアントに送信されることを知っています。クライアントにとっては役に立たないようです。
mysql-docから
彼らは本当に何のために使ったのだろうか?
これに関する任意のアイデアをいただければ幸いです。
mysql サーバーとクライアント プロトコルを見ると、 Ok_Packet に「影響を受ける行」と「last-insert-id」の 2 つの列があります。
Ok_packet は、クライアントから送信されたコマンドの応答としてサーバーからクライアントに送信されることを知っています。クライアントにとっては役に立たないようです。
mysql-docから
彼らは本当に何のために使ったのだろうか?
これに関する任意のアイデアをいただければ幸いです。
ある時点で、MySQL クライアント/サーバー プロトコルに関するこの優れた情報集にリンクしていましたが、最初に読んだとき、公式ドキュメントの何よりもよく整理され、完全であると結論付けました。
このプロトコルは、複数の方法でさまざまなことを行うことをサポートしていますCOM_DROP_DB
。 0x03 の後に文字列 "DROP DATABASE schema_name" が続き、 0x07 0x04 を送信するだけでCOM_QUERY
実行できます。FLUSH TABLES
すべての OK パケットでクライアントに返される rows_affected と last_insert_id の 2 つの値は、クライアントにとって特に便利です。
各クエリの後、方向転換して別のクエリを送信できます。
SELECT ROW_COUNT(), LAST_INSERT_ID();
...しかし、なぜ?これは、ネットワークを介したサーバーへの別の往復、解析される別のクエリ、および生成される別の応答メッセージであり、すべて不必要です。
そのうちの 1 つは常に使用されており、あまり考えたことがないかもしれません。
mysql> DELETE FROM t1 WHERE id = 6;
Query OK, 1 row affected (0.09 sec)
サーバーは「クエリ OK、影響を受ける 1 行」を送信しませんでした。それは、rows_affected 値が 1 に設定された OK パケットを送信しました。クライアントは、それをメッセージに変換しました。タイミングもクライアントが行いました。
クライアントが送信しなかった一般的なクエリ ログから確認できますSELECT ROW_COUNT()
。その値を取得します。
多くのライブラリは、影響を受ける行または最後の挿入 ID を返すメソッドを公開しています。クエリをサーバーに送り返して尋ねる必要はありません。サーバーがこの情報を必要としない場合でも自発的に送信する低コストは、同じ情報を取得するために別のクエリを作成してサーバーに送り返すよりも好ましいように思えます。
また、プロトコル トランザクションを含むログではないバイナリ ログに関して、まだ混乱していることに気付くと思います。バイナリ ログは、クライアント/サーバー プロトコルと多くのデータ構造を共有しますが、クライアント/サーバー プロトコルとは別のものであり、特に密接に関連するものではありません。binlog には、サーバーで発生した変更の順次記録が含まれます。これを使用して、スレーブ サーバーは、マスターに適用された独自のデータに同じ変更を適用できます。これにより、2 つのサーバーのデータ セットを長期的に同一に保つことができます。 ..しかし、サーバー上で発生した変更のみが含まれ、それらは「イベント」と呼ばれる構造のグループに記録されます... また、変更は、マスターで実行された実際の削除/挿入/更新ステートメントとして (ステートメント ベースのロギング)、または変更された実際の行の実際のデータのみを含む行イメージ (行ベースのログ) として文書化されます。ロギング)。行ベースのロギングでは、列は序数の位置によって参照されるため、列名はプロトコルのどこにもありません。これは、レプリケーションに必要なものすべてです。もちろん、スレーブがマスターに接続してイベント ストリームを受信するために、クライアント/サーバー プロトコルの小さなサブセットが使用されますが、これはおそらく必要以上に利便性の問題でした。列は序数の位置によって参照されるため、レプリケーションに必要なのはそれだけです。もちろん、スレーブがマスターに接続してイベント ストリームを受信するために、クライアント/サーバー プロトコルの小さなサブセットが使用されますが、これはおそらく必要以上に利便性の問題でした。列は序数の位置によって参照されるため、レプリケーションに必要なのはそれだけです。もちろん、スレーブがマスターに接続してイベント ストリームを受信するために、クライアント/サーバー プロトコルの小さなサブセットが使用されますが、これはおそらく必要以上に利便性の問題でした。