Documentation Home
MySQL Internals Manual
Download this Manual
EPUB - 1.2Mb


14.1.3.1 OK_Packet

An OK packet is sent from the server to the client to signal successful completion of a command. As of MySQL 5.7.5, OK packes are also used to indicate EOF, and EOF packets are deprecated.

If CLIENT_PROTOCOL_41 is set, the packet contains a warning count.

Table 14.1 Payload of OK Packet

Type Name Description
int<1> header [00] or [fe] the OK packet header
int<lenenc> affected_rows affected rows
int<lenenc> last_insert_id last insert-id
if capabilities & CLIENT_PROTOCOL_41 {
  int<2> status_flags Status Flags
  int<2> warnings number of warnings
} elseif capabilities & CLIENT_TRANSACTIONS {
  int<2> status_flags Status Flags
}
if capabilities & CLIENT_SESSION_TRACK {
  string<lenenc> info human readable status information
  if status_flags & SERVER_SESSION_STATE_CHANGED {
    string<lenenc> session_state_changes session state info
  }
} else {
  string<EOF> info human readable status information
}

These rules distinguish whether the packet represents OK or EOF:

  • OK: header = 0 and length of packet > 7

  • EOF: header = 0xfe and length of packet < 9

To ensure backward compatibility between old (prior to 5.7.5) and new (5.7.5 and up) versions of MySQL, new clients advertise the CLIENT_DEPRECATE_EOF flag:

  • Old clients do not know about this flag and do not advertise it. Consequently, the server does not send OK packets that represent EOF. (Old servers never do this, anyway. New servers recognize the absence of the flag to mean they should not.)

  • New clients advertise this flag. Old servers do not know this flag and do not send OK packets that represent EOF. New servers recognize the flag and can send OK packets that represent EOF.

Example

OK with CLIENT_PROTOCOL_41. 0 affected rows, last-insert-id was 0, AUTOCOMMIT enabled, 0 warnings. No further info.

07 00 00 02 00 00 00 02    00 00 00
...........
14.1.3.1.1 Session State Information

State-change information is sent in the OK packet as a array of state-change blocks which are made up of:

Table 14.2 Layout of Changed Session Information

Type Name Description
int<1> type type of data
string<lenenc> data data of the changed session info

Table 14.3 Types of State Change Information

Name Value Description
SESSION_TRACK_SYSTEM_VARIABLES 0x00 one or more system variables changed. See also: session_track_system_variables
SESSION_TRACK_SCHEMA 0x01 schema changed. See also: session_track_schema
SESSION_TRACK_STATE_CHANGE 0x02 "track state change" changed. See also: session_track_state_change
SESSION_TRACK_GTIDS 0x03 "track GTIDs" changed. See also: session_track_gtids

Interpretation of the data field depends on the type value:

SESSION_TRACK_SYSTEM_VARIABLES
Type Name Description
string<lenenc> name name of the changed system variable
string<lenenc> value value of the changed system variable
Example

After a SET autocommit = OFF statement:

1

The length of the data field.

SESSION_TRACK_SCHEMA
Type Name Description
string<lenenc> name name of the changed schema
Example

After a USE test statement:

01 05 04 74 65 73 74
...test
SESSION_TRACK_STATE_CHANGE

A flag byte that indicates whether session state changes occurred. This flag is represented as an ASCII value. Example:

Type Name Description
string<lenenc> is_tracked [31] ("1") if state tracking got enabled.
Example

After a SET SESSION session_track_state_change = 1 statement:

03 02 01 31                                      
...1            

User Comments
  Posted by Naoki INADA on August 29, 2016
> OK: header = 0 and length of packet > 7

It may be "length of packet > 6"
Sign Up Login You must be logged in to post a comment.