What do "affected rows" and "last_insert_id" in mysql sever & client protocol used for?

Question

As seeing to the mysql server and client protocol , I find the two columns "affected rows" and "last-insert-id" in Ok_Packet.
I know the Ok_packet is sent by server to the client as a response of commands sended by a client. It seems useless for the client. from mysql-doc

I wonder what do they really used for?

Any idea about this will be appreciated.

Answer 1

At one point, you had linked to this excellent compilation of information about the MySQL client/server protocol, which I concluding, on first reading, to be better organized and more complete than anything in the official documentation.

The protocol supports doing a number of different thing in more than one way... for example, you can drop a database by sending a COM_DROP_DB packet, consisting only of only 0x06 and the name of the database, as well as by sending a COM_QUERY packet containing 0x03 followed by the string "DROP DATABASE schema_name", and you can execute FLUSH TABLES by just sending 0x07 0x04.

The two values returned to the client with every OK packet for rows_affected and last_insert_id are particularly useful to the client, because they allow you to obtain two commonly needed pieces of information without having to turn around and ask for them.

After each query, you could turn around and send another query:

SELECT ROW_COUNT(), LAST_INSERT_ID();

...but why? That's another round-trip across the network to the server, another query to be parsed and another response message to generate, all unnecessarily.

One of them is used all the time, and you may not have thought much about it:

mysql> DELETE FROM t1 WHERE id = 6;
Query OK, 1 row affected (0.09 sec)

The server did not send "Query OK, 1 row affected." It sent an OK packet with the rows_affected value set to 1. The client turned that into the message you see. The client also did the timing.

You can confirm from the general query log that the client did not send SELECT ROW_COUNT(); to get that value.

Many libraries expose a method that returns the rows affected or the last insert ID without having to send a query back to the server to ask it. The low cost of the server sending this information spontaneously even when not needed seems, to me, to be preferable than having to craft and send another query back to the server to obtain the same information.

I think you will also find that there is still some confusion on your part with regard to the binary log, which is not a log containing protocol transactions. The binary log shares a number of data structures with the client/server protocol, but it is a separate and not particularly closely-related thing to the client/server protocol. The binlog contains a sequential record of the changes that occurred on a server, which a slave server can use to apply the same changes to its own data that were applied to the master, and thereby keep the two servers' data sets identical over time... but it only contains the changes that occurred on the server and they are logged in groups of structures referred to as "events" ... and the changes may be documented as the actual delete/insert/update statement that was executed on the master (statement-based logging), or as row images that contain nothing but the actual data in the actual rows that were changed (row-based logging). In row-based logging, the column names are nowhere to be found in the protocol, because the columns are referenced by their ordinal positions, which is all that replication needs. Of course, a small subset of the client/server protocol is used to the slave to connect to the master and receive the event stream, but this was presumably a matter of convenience more than necessity.