Table of Contents
Tables in the performance_schema database can
be grouped as follows:
Setup tables. These tables are used to configure and display monitoring characteristics.
Current events tables. The
events_waits_current table
contains the most recent event for each thread. Other similar
tables contain current events at different levels of the event
hierarchy: events_stages_current
for stage events, and
events_statements_current for
statement events.
History tables. These tables have the same structure as the
current events tables, but contain more rows. For example, for
wait events, events_waits_history
table contains the most recent 10 events per thread.
events_waits_history_long
contains the most recent 10,000 events. Other similar tables
exist for stage and statement histories.
To change the sizes of the history tables, set the appropriate
system variables at server startup. For example, to set the
sizes of the wait event history tables, set
performance_schema_events_waits_history_size
and
performance_schema_events_waits_history_long_size.
Summary tables. These tables contain information aggregated over groups of events, including those that have been discarded from the history tables.
Instance tables. These tables document what types of objects are instrumented. An instrumented object, when used by the server, produces an event. These tables provide event names and explanatory notes or status information.
Miscellaneous tables. These do not fall into any of the other table groups.
The following table lists each Performance Schema table and provides a short description of each one.
Table 8.1 Performance Schema Tables
| Table Name | Description |
|---|---|
accounts | Connection statistics per client account |
cond_instances | synchronization object instances |
events_stages_current | Current stage events |
events_stages_history | Most recent stage events for each thread |
events_stages_history_long | Most recent stage events overall |
events_stages_summary_by_account_by_event_name | Stage events per account and event name |
events_stages_summary_by_host_by_event_name | Stage events per host name and event name |
events_stages_summary_by_thread_by_event_name | Stage waits per thread and event name |
events_stages_summary_by_user_by_event_name | Stage events per user name and event name |
events_stages_summary_global_by_event_name | Stage waits per event name |
events_statements_current | Current statement events |
events_statements_history | Most recent statement events for each thread |
events_statements_history_long | Most recent statement events overall |
events_statements_summary_by_account_by_event_name | Statement events per account and event name |
events_statements_summary_by_digest | Statement events per schema and digest value |
events_statements_summary_by_host_by_event_name | Statement events per host name and event name |
events_statements_summary_by_thread_by_event_name | Statement events per thread and event name |
events_statements_summary_by_user_by_event_name | Statement events per user name and event name |
events_statements_summary_global_by_event_name | Statement events per event name |
events_waits_current | Current wait events |
events_waits_history | Most recent wait events for each thread |
events_waits_history_long | Most recent wait events overall |
events_waits_summary_by_account_by_event_name | Wait events per account and event name |
events_waits_summary_by_host_by_event_name | Wait events per host name and event name |
events_waits_summary_by_instance | Wait events per instance |
events_waits_summary_by_thread_by_event_name | Wait events per thread and event name |
events_waits_summary_by_user_by_event_name | Wait events per user name and event name |
events_waits_summary_global_by_event_name | Wait events per event name |
file_instances | File instances |
file_summary_by_event_name | File events per event name |
file_summary_by_instance | File events per file instance |
host_cache | Information from the internal host cache |
hosts | Connection statistics per client host name |
mutex_instances | Mutex synchronization object instances |
objects_summary_global_by_type | Object summaries |
performance_timers | Which event timers are available |
rwlock_instances | Lock synchronization object instances |
session_account_connect_attrs | Connection attributes per for the current session |
session_connect_attrs | Connection attributes for all sessions |
setup_actors | How to initialize monitoring for new foreground threads |
setup_consumers | Consumers for which event information can be stored |
setup_instruments | Classes of instrumented objects for which events can be collected |
setup_objects | Which objects should be monitored |
setup_timers | Current event timer |
socket_instances | Active connection instances |
socket_summary_by_event_name | Socket waits and I/O per event name |
socket_summary_by_instance | Socket waits and I/O per instance |
table_io_waits_summary_by_index_usage | Table I/O waits per index |
table_io_waits_summary_by_table | Table I/O waits per table |
table_lock_waits_summary_by_table | Table lock waits per table |
threads | Information about server threads |
users | Connection statistics per client user name |
The setup tables provide information about the current
instrumentation and enable the monitoring configuration to be
changed. For this reason, some columns in these tables can be
changed if you have the UPDATE
privilege.
The use of tables rather than individual variables for setup information provides a high degree of flexibility in modifying Performance Schema configuration. For example, you can use a single statement with standard SQL syntax to make multiple simultaneous configuration changes.
These setup tables are available:
setup_actors: How to initialize
monitoring for new foreground threads
setup_consumers: The
destinations to which event information can be sent and
stored
setup_instruments: The classes
of instrumented objects for which events can be collected
setup_objects: Which objects
should be monitored
setup_timers: The current event
timer
The setup_actors table contains
information that determines whether to enable monitoring for
new foreground server threads (threads associated with client
connections). This table has a maximum size of 100 rows by
default. To change the table size, modify the
performance_schema_setup_actors_size
system variable at server startup.
For each new foreground thread, the Performance Schema matches
the user and host for the thread against the rows of the
setup_actors table. If a row from
that table matches, its ENABLED column
value is used to set the the INSTRUMENTED
column of the threads table row
for the thread. This enables instrumenting to be applied
selectively per host, user, or account (combination of host
and user). If there is no match, the
INSTRUMENTED column for the thread is set
to NO.
For background threads, there is no associated user.
INSTRUMENTED is YES by
default and setup_actors is not
consulted.
The initial contents of the
setup_actors table match any user
and host combination, so monitoring is enabled by default for
all foreground threads:
mysql> SELECT * FROM setup_actors;
+------+------+------+
| HOST | USER | ROLE |
+------+------+------+
| % | % | % |
+------+------+------+
For information about how to use the
setup_actors table to affect
event monitoring, see
Section 3.3.3.3, “Pre-Filtering by Thread”.
Modifications to the setup_actors
table affect only foreground threads created subsequent to the
modification, not existing threads. To affect existing
threads, modify the INSTRUMENTED column of
threads table rows.
The setup_actors table has these
columns:
HOST
The host name. This should be a literal name, or
'%' to mean “any host.”
USER
The user name. This should be a literal name, or
'%' to mean “any user.”
ROLE
Unused.
The setup_consumers table lists
the types of consumers for which event information can be
stored and which are enabled:
mysql> SELECT * FROM setup_consumers;
+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | NO |
| events_statements_history_long | NO |
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
| global_instrumentation | YES |
| thread_instrumentation | YES |
| statements_digest | YES |
+--------------------------------+---------+
The consumer settings in the
setup_consumers table form a
hierarchy from higher levels to lower. For detailed
information about the effect of enabling different consumers,
see Section 3.3.3.4, “Pre-Filtering by Consumer”.
Modifications to the
setup_consumers table affect
monitoring immediately.
The setup_consumers table has
these columns:
NAME
The consumer name.
ENABLED
Whether the consumer is enabled. The value is
YES or NO. This
column can be modified. If you disable a consumer, the
server does not spend time adding event information to it.
The setup_instruments table lists
classes of instrumented objects for which events can be
collected:
mysql> SELECT * FROM setup_instruments;
+------------------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+------------------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
| wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
| wait/synch/mutex/sql/LOCK_manager | YES | YES |
...
| wait/synch/rwlock/sql/LOCK_grant | YES | YES |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES |
...
| wait/io/file/sql/binlog | YES | YES |
| wait/io/file/sql/binlog_index | YES | YES |
| wait/io/file/sql/casetest | YES | YES |
| wait/io/file/sql/dbopt | YES | YES |
...
Each instrument added to the source code provides a row for
this table, even when the instrumented code is not executed.
When an instrument is enabled and executed, instrumented
instances are created, which are visible in the
*_instances tables.
Modifications to most
setup_instruments rows affect
monitoring immediately. For some instruments, modifications
are effective only at server startup; changing them at runtime
has no effect. This affects primarily mutexes, conditions, and
rwlocks in the server, although there may be other instruments
for which this is true.
For more information about the role of the
setup_instruments table in event
filtering, see
Section 3.3.3, “Event Pre-Filtering”.
The setup_instruments table has
these columns:
NAME
The instrument name. Instrument names may have multiple
parts and form a hierarchy, as discussed in
Chapter 5, Performance Schema Instrument Naming Conventions.
Events produced from execution of an instrument have an
EVENT_NAME value that is taken from the
instrument NAME value. (Events do not
really have a “name,” but this provides a way
to associate events with instruments.)
ENABLED
Whether the instrument is enabled. The value is
YES or NO. This
column can be modified. A disabled instrument produces no
events.
TIMED
Whether the instrument is timed. This column can be modified.
If an enabled instrument is not timed, the instrument code
is enabled, but the timer is not. Events produced by the
instrument have NULL for the
TIMER_START,
TIMER_END, and
TIMER_WAIT timer values. This in turn
causes those values to be ignored when calculating the
sum, minimum, maximum, and average time values in summary
tables.
The setup_objects table controls
whether the Performance Schema monitors particular objects.
This table has a maximum size of 100 rows by default. To
change the table size, modify the
performance_schema_setup_objects_size
system variable at server startup.
The initial setup_objects
contents look like this:
mysql> SELECT * FROM setup_objects;
+-------------+--------------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
+-------------+--------------------+-------------+---------+-------+
| TABLE | mysql | % | NO | NO |
| TABLE | performance_schema | % | NO | NO |
| TABLE | information_schema | % | NO | NO |
| TABLE | % | % | YES | YES |
+-------------+--------------------+-------------+---------+-------+
Modifications to the
setup_objects table affect object
monitoring immediately.
For object types listed in
setup_objects, the Performance
Schema uses the table to how to monitor them. Object matching
is based on the OBJECT_SCHEMA and
OBJECT_NAME columns. Objects for which
there is no match are not monitored.
The effect of the default object configuration is to
instrument all tables except those in the
mysql,
INFORMATION_SCHEMA, and
performance_schema databases. (Tables in
the INFORMATION_SCHEMA database are not
instrumented regardless of the contents of
setup_objects; the row for
information_schema.% simply makes this
default explicit.)
When the Performance Schema checks for a match in
setup_objects, it tries to find
more specific matches first. For example, with a table
db1.t1, it looks for a match for
'db1' and 't1', then for
'db1' and '%', then for
'%' and '%'. The order
in which matching occurs matters because different matching
setup_objects rows can have
different ENABLED and
TIMED values.
Rows can be inserted into or deleted from
setup_objects by users with the
INSERT or
DELETE privilege on the table.
For existing rows, only the ENABLED and
TIMED columns can be modified, by users
with the UPDATE privilege on
the table.
For more information about the role of the
setup_objects table in event
filtering, see
Section 3.3.3, “Event Pre-Filtering”.
The setup_objects table has these
columns:
OBJECT_TYPE
The type of object to instrument. This is always
'TABLE' (base table).
TABLE filtering affects table I/O
events (wait/io/table/sql/handler
instrument) and table lock events
(wait/lock/table/sql/handler
instrument).
OBJECT_SCHEMA
The schema that contains the object. This should be a
literal name, or '%' to mean “any
schema.”
OBJECT_NAME
The name of the instrumented object. This should be a
literal name, or '%' to mean “any
object.”
ENABLED
Whether events for the object are instrumented. The value
is YES or NO. This
column can be modified.
This column was added in MySQL 5.6.3. For earlier versions in which it is not present, the Performance Schema enables monitoring only for objects matched by some row in the table; monitoring is implicitly disabled for nonmatching objects.
TIMED
Whether events for the object are timed. This column can be modified.
The setup_timers table shows the
currently selected event timers:
mysql> SELECT * FROM setup_timers;
+-----------+-------------+
| NAME | TIMER_NAME |
+-----------+-------------+
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
+-----------+-------------+
The setup_timers.TIMER_NAME value can be
changed to select a different timer. The value can be any of
the values in the
performance_timers.TIMER_NAME column. For
an explanation of how event timing occurs, see
Section 3.3.1, “Performance Schema Event Timing”.
Modifications to the setup_timers
table affect monitoring immediately. Events already in
progress may use the original timer for the begin time and the
new timer for the end time. To avoid unpredictable results
after you make timer changes, use
TRUNCATE TABLE to reset
Performance Schema statistics.
The setup_timers table has these
columns:
NAME
The type of instrument the timer is used for.
TIMER_NAME
The timer that applies to the instrument type. This column can be modified.
Instance tables document what types of objects are instrumented. They provide event names and explanatory notes or status information:
cond_instances: Condition
synchronization object instances
file_instances: File instances
mutex_instances: Mutex
synchronization object instances
rwlock_instances: Lock
synchronization object instances
socket_instances: Active
connection instances
These tables list instrumented synchronization objects, files,
and connections. There are three types of synchronization
objects: cond, mutex, and
rwlock. Each instance table has an
EVENT_NAME or NAME column
to indicate the instrument associated with each row. Instrument
names may have multiple parts and form a hierarchy, as discussed
in Chapter 5, Performance Schema Instrument Naming Conventions.
The mutex_instances.LOCKED_BY_THREAD_ID and
rwlock_instances.WRITE_LOCKED_BY_THREAD_ID
columns are extremely important for investigating performance
bottlenecks or deadlocks. For examples of how to use them for
this purpose, see Chapter 12, Using the Performance Schema to Diagnose Problems
The cond_instances table lists
all the conditions seen by the Performance Schema while the
server executes. A condition is a synchronization mechanism
used in the code to signal that a specific event has happened,
so that a thread waiting for this condition can resume work.
When a thread is waiting for something to happen, the condition name is an indication of what the thread is waiting for, but there is no immediate way to tell which other thread, or threads, will cause the condition to happen.
The cond_instances table has
these columns:
NAME
The instrument name associated with the condition.
OBJECT_INSTANCE_BEGIN
The address in memory of the instrumented condition.
The file_instances table lists
all the files seen by the Performance Schema when executing
file I/O instrumentation. If a file on disk has never been
opened, it will not be in
file_instances. When a file is
deleted from the disk, it is also removed from the
file_instances table.
The file_instances table has
these columns:
FILE_NAME
The file name.
EVENT_NAME
The instrument name associated with the file.
OPEN_COUNT
The count of open handles on the file. If a file was
opened and then closed, it was opened 1 time, but
OPEN_COUNT will be 0. To list all the
files currently opened by the server, use WHERE
OPEN_COUNT > 0.
The mutex_instances table lists
all the mutexes seen by the Performance Schema while the
server executes. A mutex is a synchronization mechanism used
in the code to enforce that only one thread at a given time
can have access to some common resource. The resource is said
to be “protected” by the mutex.
When two threads executing in the server (for example, two user sessions executing a query simultaneously) do need to access the same resource (a file, a buffer, or some piece of data), these two threads will compete against each other, so that the first query to obtain a lock on the mutex will cause the other query to wait until the first is done and unlocks the mutex.
The work performed while holding a mutex is said to be in a “critical section,” and multiple queries do execute this critical section in a serialized way (one at a time), which is a potential bottleneck.
The mutex_instances table has
these columns:
NAME
The instrument name associated with the mutex.
OBJECT_INSTANCE_BEGIN
The address in memory of the instrumented mutex.
LOCKED_BY_THREAD_ID
When a thread currently has a mutex locked,
LOCKED_BY_THREAD_ID is the
THREAD_ID of the locking thread,
otherwise it is NULL.
For every mutex instrumented in the code, the Performance Schema provides the following information.
The setup_instruments table
lists the name of the instrumentation point, with the
prefix wait/synch/mutex/.
When some code creates a mutex, a row is added to the
mutex_instances table. The
OBJECT_INSTANCE_BEGIN column is a
property that uniquely identifies the mutex.
When a thread attempts to lock a mutex, the
events_waits_current table
shows a row for that thread, indicating that it is waiting
on a mutex (in the EVENT_NAME column),
and indicating which mutex is waited on (in the
OBJECT_INSTANCE_BEGIN column).
When a thread succeeds in locking a mutex:
events_waits_current
shows that the wait on the mutex is completed (in the
TIMER_END and
TIMER_WAIT columns)
The completed wait event is added to the
events_waits_history and
events_waits_history_long
tables
mutex_instances shows
that the mutex is now owned by the thread (in the
THREAD_ID column).
When a thread unlocks a mutex,
mutex_instances shows that
the mutex now has no owner (the
THREAD_ID column is
NULL).
When a mutex object is destroyed, the corresponding row is
removed from mutex_instances.
By performing queries on both of the following tables, a monitoring application or a DBA can detect bottlenecks or deadlocks between threads that involve mutexes:
events_waits_current, to see
what mutex a thread is waiting for
mutex_instances, to see which
other thread currently owns a mutex
The rwlock_instances table lists
all the rwlock instances (read write locks)
seen by the Performance Schema while the server executes. An
rwlock is a synchronization mechanism used
in the code to enforce that threads at a given time can have
access to some common resource following certain rules. The
resource is said to be “protected” by the
rwlock. The access is either shared (many
threads can have a read lock at the same time) or exclusive
(only one thread can have a write lock at a given time).
Depending on how many threads are requesting a lock, and the nature of the locks requested, access can be either granted in shared mode, granted in exclusive mode, or not granted at all, waiting for other threads to finish first.
The rwlock_instances table has
these columns:
NAME
The instrument name associated with the lock.
OBJECT_INSTANCE_BEGIN
The address in memory of the instrumented lock.
WRITE_LOCKED_BY_THREAD_ID
When a thread currently has an rwlock
locked in exclusive (write) mode,
WRITE_LOCKED_BY_THREAD_ID is the
THREAD_ID of the locking thread,
otherwise it is NULL.
READ_LOCKED_BY_COUNT
When a thread currently has an rwlock
locked in shared (read) mode,
READ_LOCKED_BY_COUNT is incremented by
1. This is a counter only, so it cannot be used directly
to find which thread holds a read lock, but it can be used
to see whether there is a read contention on an
rwlock, and see how many readers are
currently active.
By performing queries on both of the following tables, a monitoring application or a DBA may detect some bottlenecks or deadlocks between threads that involve locks:
events_waits_current, to see
what rwlock a thread is waiting for
rwlock_instances, to see
which other thread currently owns an
rwlock
There is a limitation: The
rwlock_instances can be used only
to identify the thread holding a write lock, but not the
threads holding a read lock.
The socket_instances table
provides a real-time snapshot of the active connections to the
MySQL server. The table contains one row per TCP/IP or Unix
socket file connection. Information available in this table
provides a real-time snapshot of the active connections to the
server. (Additional information is available in socket summary
tables, including network activity such as socket operations
and number of bytes transmitted and received; see
Section 8.9.8, “Socket Summary Tables”).
mysql> SELECT * FROM socket_instances\G
*************************** 1. row ***************************
EVENT_NAME: wait/io/socket/sql/server_unix_socket
OBJECT_INSTANCE_BEGIN: 4316619408
THREAD_ID: 1
SOCKET_ID: 16
IP:
PORT: 0
STATE: ACTIVE
*************************** 2. row ***************************
EVENT_NAME: wait/io/socket/sql/client_connection
OBJECT_INSTANCE_BEGIN: 4316644608
THREAD_ID: 21
SOCKET_ID: 39
IP: 127.0.0.1
PORT: 55233
STATE: ACTIVE
*************************** 3. row ***************************
EVENT_NAME: wait/io/socket/sql/server_tcpip_socket
OBJECT_INSTANCE_BEGIN: 4316699040
THREAD_ID: 1
SOCKET_ID: 14
IP: 0.0.0.0
PORT: 50603
STATE: ACTIVE
Socket instruments have names of the form
wait/io/socket/sql/
and are used like this:
socket_type
The server has a listening socket for each network
protocol that it supports. The instruments associated with
listening sockets for TCP/IP or Unix socket file
connections have a socket_type
value of server_tcpip_socket or
server_unix_socket, respectively.
When a listening socket detects a connection, the server
transfers the connection to a new socket managed by a
separate thread. The instrument for the new connection
thread has a socket_type value
of client_connection.
When a connection terminates, the row in
socket_instances
corresponding to it is deleted.
The socket_instances table has
these columns:
EVENT_NAME
The name of the wait/io/socket/*
instrument that produced the event. This is a
NAME value from the
setup_instruments table.
Instrument names may have multiple parts and form a
hierarchy, as discussed in
Chapter 5, Performance Schema Instrument Naming Conventions.
OBJECT_INSTANCE_BEGIN
This column uniquely identifies the socket. The value is the address of an object in memory.
THREAD_ID
The internal thread identifier assigned by the server. Each socket is managed by a single thread, so each socket can be mapped to a thread which can be mapped to a server process.
SOCKET_ID
The internal file handle assigned to the socket.
IP
The client IP address. The value may be either an IPv4 or IPv6 address, or blank to indicate a Unix socket file connection.
PORT
The TCP/IP port number, in the range from 0 to 65535.
STATE
The socket status, either IDLE or
ACTIVE. Wait times for active sockets
are tracked using the corresponding socket instrument.
Wait times for idle sockets are tracked using the
idle instrument.
A socket is idle if it is waiting for a request from the
client. When a socket becomes idle, the event row in
socket_instances that is
tracking the socket switches from a status of
ACTIVE to IDLE. The
EVENT_NAME value remains
wait/io/socket/*, but timing for the
instrument is suspended. Instead, an event is generated in
the events_waits_current
table with an EVENT_NAME value of
idle.
When the next request is received, the
idle event terminates, the socket
instance switches from IDLE to
ACTIVE, and timing of the socket
instrument resumes.
The IP:PORT column combination value
identifies the connection. This combination value is used in
the OBJECT_NAME column of the
events_waits_
tables, to identify the connection from which socket events
come:
xxx
For the Unix domain listener socket
(server_unix_socket), the port is 0,
and the IP is ''.
For client connections via the Unix domain listener
(client_connection), the port is 0, and
the IP is ''.
For the TCP/IP server listener socket
(server_tcpip_socket), the port is
always the master port (for example, 3306), and the IP is
always 0.0.0.0.
For client connections via the TCP/IP listener
(client_connection), the port is
whatever the server assigns, but never 0. The IP is the IP
of the originating host (127.0.0.1 or
::1 for the local host)
The socket_instances table was
added in MySQL 5.6.3.
These tables store wait events:
events_waits_current: Current
wait events
events_waits_history: The most
recent wait events for each thread
events_waits_history_long: The
most recent wait events overall
The following sections describe those tables. There are also summary tables that aggregate information about wait events; see Section 8.9.1, “Event Wait Summary Tables”.
To enable collection of wait events, enable the relevant instruments and consumers.
The setup_instruments table
contains instruments with names that begin with
wait. For example:
mysql>SELECT * FROM setup_instruments->WHERE NAME LIKE 'wait/io/file/innodb%';+--------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +--------------------------------------+---------+-------+ | wait/io/file/innodb/innodb_data_file | YES | YES | | wait/io/file/innodb/innodb_log_file | YES | YES | | wait/io/file/innodb/innodb_temp_file | YES | YES | +--------------------------------------+---------+-------+ mysql>SELECT * FROM setup_instruments WHERE->NAME LIKE 'wait/io/socket/%';+----------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +----------------------------------------+---------+-------+ | wait/io/socket/sql/server_tcpip_socket | NO | NO | | wait/io/socket/sql/server_unix_socket | NO | NO | | wait/io/socket/sql/client_connection | NO | NO | +----------------------------------------+---------+-------+
To modify collection of wait events, change the
ENABLED and TIMING columns
of the relevant instruments. For example:
mysql>UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'->WHERE NAME LIKE 'wait/io/socket/sql/%';
The setup_consumers table contains
consumer values with names corresponding to the current and
recent wait event table names. These consumers may be used to
filter collection of wait events. The wait consumers are
disabled by default:
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%waits%';
+---------------------------+---------+
| NAME | ENABLED |
+---------------------------+---------+
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
+---------------------------+---------+
To enable all wait consumers, do this:
mysql>UPDATE setup_consumers SET ENABLED = 'YES'->WHERE NAME LIKE '%waits%';
The setup_timers table contains a
row with a NAME value of
wait that indicates the unit for wait event
timing. The default unit is CYCLE.
mysql> SELECT * FROM setup_timers WHERE NAME = 'wait';
+------+------------+
| NAME | TIMER_NAME |
+------+------------+
| wait | CYCLE |
+------+------------+
To change the timing unit, modify the
TIMER_NAME value:
mysql>UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND'->WHERE NAME = 'wait';
For additional information about configuring event collection, see Chapter 3, Performance Schema Configuration.
The events_waits_current table
contains current wait events, one row per thread showing the
current status of the thread's most recent monitored wait
event.
The events_waits_current table
can be truncated with TRUNCATE
TABLE.
Of the tables that contain wait event rows,
events_waits_current is the most
fundamental. Other tables that contain wait event rows are
logically derived from the current events. For example, the
events_waits_history and
events_waits_history_long tables
are collections of the most recent wait events, up to a fixed
number of rows.
For information about configuration of wait event collection, see Section 8.4, “Performance Schema Wait Event Tables”.
The events_waits_current table
has these columns:
THREAD_ID, EVENT_ID
The thread associated with the event and the thread
current event number when the event starts. The
THREAD_ID and
EVENT_ID values taken together form a
primary key that uniquely identifies the row. No two rows
will have the same pair of values.
END_EVENT_ID
This column is set to NULL when the
event starts and updated to the thread current event
number when the event ends. This column was added in MySQL
5.6.4.
EVENT_NAME
The name of the instrument that produced the event. This
is a NAME value from the
setup_instruments table.
Instrument names may have multiple parts and form a
hierarchy, as discussed in
Chapter 5, Performance Schema Instrument Naming Conventions.
SOURCE
The name of the source file containing the instrumented code that produced the event and the line number in the file at which the instrumentation occurs. This enables you to check the source to determine exactly what code is involved. For example, if a mutex or lock is being blocked, you can check the context in which this occurs.
TIMER_START,
TIMER_END,
TIMER_WAIT
Timing information for the event. The unit for these
values is picoseconds (trillionths of a second). The
TIMER_START and
TIMER_END values indicate when event
timing started and ended. TIMER_WAIT is
the event elapsed time (duration).
If an event has not finished, TIMER_END
and TIMER_WAIT are
NULL before MySQL 5.6.26. As of 5.6.26,
TIMER_END is the current timer value
and TIMER_WAIT is the time elapsed so
far (TIMER_END −
TIMER_START).
If an event is produced from an instrument that has
TIMED = NO, timing information is not
collected, and TIMER_START,
TIMER_END, and
TIMER_WAIT are all
NULL.
For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 3.3.1, “Performance Schema Event Timing”.
SPINS
For a mutex, the number of spin rounds. If the value is
NULL, the code does not use spin rounds
or spinning is not instrumented.
OBJECT_SCHEMA,
OBJECT_NAME,
OBJECT_TYPE,
OBJECT_INSTANCE_BEGIN
These columns identify the object “being acted on.” What that means depends on the object type.
For a synchronization object (cond,
mutex, rwlock):
OBJECT_SCHEMA,
OBJECT_NAME, and
OBJECT_TYPE are
NULL.
OBJECT_INSTANCE_BEGIN is the
address of the synchronization object in memory.
For a file I/O object:
OBJECT_SCHEMA is
NULL.
OBJECT_NAME is the file name.
OBJECT_TYPE is
FILE.
OBJECT_INSTANCE_BEGIN is an address
in memory.
For a socket object:
OBJECT_NAME is the
IP:PORT value for the socket.
OBJECT_INSTANCE_BEGIN is an address
in memory.
For a table I/O object:
OBJECT_SCHEMA is the name of the
schema that contains the table.
OBJECT_NAME is the table name.
OBJECT_TYPE is
TABLE for a persistent base table
or TEMPORARY TABLE for a temporary
table.
OBJECT_INSTANCE_BEGIN is an address
in memory.
An OBJECT_INSTANCE_BEGIN value itself
has no meaning, except that different values indicate
different objects.
OBJECT_INSTANCE_BEGIN can be used for
debugging. For example, it can be used with GROUP
BY OBJECT_INSTANCE_BEGIN to see whether the load
on 1,000 mutexes (that protect, say, 1,000 pages or blocks
of data) is spread evenly or just hitting a few
bottlenecks. This can help you correlate with other
sources of information if you see the same object address
in a log file or another debugging or performance tool.
INDEX_NAME
The name of the index used. PRIMARY
indicates the table primary index. NULL
means that no index was used.
NESTING_EVENT_ID
The EVENT_ID value of the event within
which this event is nested. Before MySQL 5.6.3, this
column is always NULL.
NESTING_EVENT_TYPE
The nesting event type. The value is
STATEMENT, STAGE, or
WAIT. This column was added in MySQL
5.6.3.
OPERATION
The type of operation performed, such as
lock, read, or
write.
NUMBER_OF_BYTES
The number of bytes read or written by the operation. For
table I/O waits (events for the
wait/io/table/sql/handler instrument),
NUMBER_OF_BYTES is
NULL.
FLAGS
Reserved for future use.
The events_waits_history table
contains the most recent N wait
events per thread. The value of N
is autosized at server startup. To set the table size
explicitly, set the
performance_schema_events_waits_history_size
system variable at server startup. Wait events are not added
to the table until they have ended. As new events are added,
older events are discarded if the table is full.
The events_waits_history table
has the same structure as
events_waits_current. See
Section 8.4.1, “The events_waits_current Table”.
The events_waits_history table
can be truncated with TRUNCATE
TABLE.
For information about configuration of wait event collection, see Section 8.4, “Performance Schema Wait Event Tables”.
The events_waits_history_long
table contains the most recent N
wait events. The value of N is
autosized at server startup. To set the table size explicitly,
set the
performance_schema_events_waits_history_long_size
system variable at server startup. Wait events are not added
to the table until they have ended. As new events are added,
older events are discarded if the table is full. When a thread
ends, its rows are removed from the table.
The events_waits_history_long
table has the same structure as
events_waits_current. See
Section 8.4.1, “The events_waits_current Table”.
The events_waits_history_long
table can be truncated with TRUNCATE
TABLE.
For information about configuration of wait event collection, see Section 8.4, “Performance Schema Wait Event Tables”.
As of MySQL 5.6.3, the Performance Schema instruments stages,
which are steps during the statement-execution process, such as
parsing a statement, opening a table, or performing a
filesort operation. Stages correspond to the
thread states displayed by SHOW
PROCESSLIST or that are visible in the
INFORMATION_SCHEMA.PROCESSLIST
table. Stages begin and end when state values change.
Within the event hierarchy, wait events nest within stage events, which nest within statement events.
These tables store stage events:
events_stages_current: Current
stage events
events_stages_history: The most
recent stage events for each thread
events_stages_history_long: The
most recent stage events overall
The following sections describe those tables. There are also summary tables that aggregate information about stage events; see Section 8.9.2, “Stage Summary Tables”.
To enable collection of stage events, enable the relevant instruments and consumers.
The setup_instruments table
contains instruments with names that begin with
stage. These instruments are disabled by
default. For example:
mysql> SELECT * FROM setup_instruments WHERE NAME RLIKE 'stage/sql/[a-c]';
+----------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+----------------------------------------------------+---------+-------+
| stage/sql/After create | NO | NO |
| stage/sql/allocating local table | NO | NO |
| stage/sql/altering table | NO | NO |
| stage/sql/committing alter table to storage engine | NO | NO |
| stage/sql/Changing master | NO | NO |
| stage/sql/Checking master version | NO | NO |
| stage/sql/checking permissions | NO | NO |
| stage/sql/checking privileges on cached query | NO | NO |
| stage/sql/checking query cache for query | NO | NO |
| stage/sql/cleaning up | NO | NO |
| stage/sql/closing tables | NO | NO |
| stage/sql/Connecting to master | NO | NO |
| stage/sql/converting HEAP to MyISAM | NO | NO |
| stage/sql/Copying to group table | NO | NO |
| stage/sql/Copying to tmp table | NO | NO |
| stage/sql/copy to tmp table | NO | NO |
| stage/sql/Creating delayed handler | NO | NO |
| stage/sql/Creating sort index | NO | NO |
| stage/sql/creating table | NO | NO |
| stage/sql/Creating tmp table | NO | NO |
+----------------------------------------------------+---------+-------+
To modify collection of stage events, change the
ENABLED and TIMING columns
of the relevant instruments. For example:
mysql>UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'->WHERE NAME = 'stage/sql/altering table';
The setup_consumers table contains
consumer values with names corresponding to the current and
recent stage event table names. These consumers may be used to
filter collection of stage events. The stage consumers are
disabled by default:
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%stages%';
+----------------------------+---------+
| NAME | ENABLED |
+----------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
+----------------------------+---------+
To enable all stage consumers, do this:
mysql>UPDATE setup_consumers SET ENABLED = 'YES'->WHERE NAME LIKE '%stages%';
The setup_timers table contains a
row with a NAME value of
stage that indicates the unit for stage event
timing. The default unit is NANOSECOND.
mysql> SELECT * FROM setup_timers WHERE NAME = 'stage';
+-------+------------+
| NAME | TIMER_NAME |
+-------+------------+
| stage | NANOSECOND |
+-------+------------+
To change the timing unit, modify the
TIMER_NAME value:
mysql>UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'->WHERE NAME = 'stage';
For additional information about configuring event collection, see Chapter 3, Performance Schema Configuration.
The events_stages_current table
contains current stage events, one row per thread showing the
current status of the thread's most recent monitored stage
event.
The events_stages_current table
can be truncated with TRUNCATE
TABLE.
Of the tables that contain stage event rows,
events_stages_current is the most
fundamental. Other tables that contain stage event rows are
logically derived from the current events. For example, the
events_stages_history and
events_stages_history_long tables
are collections of the most recent stage events, up to a fixed
number of rows.
For information about configuration of stage event collection, see Section 8.5, “Performance Schema Stage Event Tables”.
The events_stages_current table
has these columns:
THREAD_ID, EVENT_ID
The thread associated with the event and the thread
current event number when the event starts. The
THREAD_ID and
EVENT_ID values taken together form a
primary key that uniquely identifies the row. No two rows
will have the same pair of values.
END_EVENT_ID
This column is set to NULL when the
event starts and updated to the thread current event
number when the event ends. This column was added in MySQL
5.6.4.
EVENT_NAME
The name of the instrument that produced the event. This
is a NAME value from the
setup_instruments table.
Instrument names may have multiple parts and form a
hierarchy, as discussed in
Chapter 5, Performance Schema Instrument Naming Conventions.
SOURCE
The name of the source file containing the instrumented code that produced the event and the line number in the file at which the instrumentation occurs. This enables you to check the source to determine exactly what code is involved.
TIMER_START,
TIMER_END,
TIMER_WAIT
Timing information for the event. The unit for these
values is picoseconds (trillionths of a second). The
TIMER_START and
TIMER_END values indicate when event
timing started and ended. TIMER_WAIT is
the event elapsed time (duration).
If an event has not finished, TIMER_END
and TIMER_WAIT are
NULL before MySQL 5.6.26. As of 5.6.26,
TIMER_END is the current timer value
and TIMER_WAIT is the time elapsed so
far (TIMER_END −
TIMER_START).
If an event is produced from an instrument that has
TIMED = NO, timing information is not
collected, and TIMER_START,
TIMER_END, and
TIMER_WAIT are all
NULL.
For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 3.3.1, “Performance Schema Event Timing”.
NESTING_EVENT_ID
The EVENT_ID value of the event within
which this event is nested. The nesting event for a stage
event is usually a statement event.
NESTING_EVENT_TYPE
The nesting event type. The value is
STATEMENT, STAGE, or
WAIT.
The events_stages_current table
was added in MySQL 5.6.3.
The events_stages_history table
contains the most recent N stage
events per thread. The value of N
is autosized at server startup. To set the table size
explicitly, set the
performance_schema_events_stages_history_size
system variable at server startup. Stage events are not added
to the table until they have ended. As new events are added,
older events are discarded if the table is full.
The events_stages_history table
has the same structure as
events_stages_current. See
Section 8.5.1, “The events_stages_current Table”.
The events_stages_history table
can be truncated with TRUNCATE
TABLE.
The events_stages_history table
was added in MySQL 5.6.3.
For information about configuration of stage event collection, see Section 8.5, “Performance Schema Stage Event Tables”.
The events_stages_history_long
table contains the most recent N
stage events. The value of N is
autosized at server startup. To set the table size explicitly,
set the
performance_schema_events_stages_history_long_size
system variable at server startup. Stage events are not added
to the table until they have ended. As new events are added,
older events are discarded if the table is full. When a thread
ends, its rows are removed from the table.
The events_stages_history_long
table has the same structure as
events_stages_current. See
Section 8.5.1, “The events_stages_current Table”.
The events_stages_history_long
table can be truncated with TRUNCATE
TABLE.
The events_stages_history_long
table was added in MySQL 5.6.3.
For information about configuration of stage event collection, see Section 8.5, “Performance Schema Stage Event Tables”.
As of MySQL 5.6.3, the Performance Schema instruments statement execution. Statement events occur at a high level of the event hierarchy: Wait events nest within stage events, which nest within statement events.
These tables store statement events:
events_statements_current:
Current statement events
events_statements_history: The
most recent statement events for each thread
events_statements_history_long:
The most recent statement events overall
The following sections describe those tables. There are also summary tables that aggregate information about statement events; see Section 8.9.3, “Statement Summary Tables”.
To enable collection of statement events, enable the relevant instruments and consumers.
The setup_instruments table
contains instruments with names that begin with
statement. These instruments are enabled by
default:
mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'statement/%';
+---------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+---------------------------------------------+---------+-------+
| statement/sql/select | YES | YES |
| statement/sql/create_table | YES | YES |
| statement/sql/create_index | YES | YES |
...
| statement/sp/stmt | YES | YES |
| statement/sp/set | YES | YES |
| statement/sp/set_trigger_field | YES | YES |
| statement/scheduler/event | YES | YES |
| statement/com/Sleep | YES | YES |
| statement/com/Quit | YES | YES |
| statement/com/Init DB | YES | YES |
...
| statement/abstract/Query | YES | YES |
| statement/abstract/new_packet | YES | YES |
| statement/abstract/relay_log | YES | YES |
+---------------------------------------------+---------+-------+
To modify collection of statement events, change the
ENABLED and TIMING columns
of the relevant instruments. For example:
mysql>UPDATE setup_instruments SET ENABLED = 'NO'->WHERE NAME LIKE 'statement/com/%';
The setup_consumers table contains
consumer values with names corresponding to the current and
recent statement event table names, and the statement digest
consumer. These consumers may be used to filter collection of
statement events and statement digesting. Only
events_statements_current and
statements_digest are enabled by default:
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%statements%';
+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| events_statements_current | YES |
| events_statements_history | NO |
| events_statements_history_long | NO |
| statements_digest | YES |
+--------------------------------+---------+
To enable all statement consumers, do this:
mysql>UPDATE setup_consumers SET ENABLED = 'YES'->WHERE NAME LIKE '%statements%';
The setup_timers table contains a
row with a NAME value of
statement that indicates the unit for
statement event timing. The default unit is
NANOSECOND.
mysql> SELECT * FROM setup_timers WHERE NAME = 'statement';
+-----------+------------+
| NAME | TIMER_NAME |
+-----------+------------+
| statement | NANOSECOND |
+-----------+------------+
To change the timing unit, modify the
TIMER_NAME value:
mysql>UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'->WHERE NAME = 'statement';
For additional information about configuring event collection, see Chapter 3, Performance Schema Configuration.
Statement monitoring begins from the moment the server sees that activity is requested on a thread, to the moment when all activity has ceased. Typically, this means from the time the server gets the first packet from the client to the time the server has finished sending the response. Monitoring occurs only for top-level statements. Statements within stored programs and subqueries are not seen separately.
When the Performance Schema instruments a request (server command or SQL statement), it uses instrument names that proceed in stages from more general (or “abstract”) to more specific until it arrives at a final instrument name.
Final instrument names correspond to server commands and SQL statements:
Server commands correspond to the
COM_
defined in the xxx codesmysql_com.h header file
and processed in sql/sql_parse.cc.
Examples are COM_PING and
COM_QUIT. Instruments for commands have
names that begin with statement/com, such
as statement/com/Ping and
statement/com/Quit.
SQL statements are expressed as text, such as
DELETE FROM t1 or SELECT * FROM
t2. Instruments for SQL statements have names that
begin with statement/sql, such as
statement/sql/delete and
statement/sql/select.
Some final instrument names are specific to error handling:
statement/com/Error accounts for messages
received by the server that are out of band. It can be used
to detect commands sent by clients that the server does not
understand. This may be helpful for purposes such as
identifying clients that are misconfigured or using a
version of MySQL more recent than that of the server, or
clients that are attempting to attack the server.
statement/sql/error accounts for SQL
statements that fail to parse. It can be used to detect
malformed queries sent by clients. A query that fails to
parse differs from a query that parses but fails due to an
error during execution. For example, SELECT *
FROM is malformed, and the
statement/sql/error instrument is used.
By contrast, SELECT * parses but fails
with a No tables used error. In this
case, statement/sql/select is used and
the statement event contains information to indicate the
nature of the error.
A request can be obtained from any of these sources:
As a command or statement request from a client, which sends the request as packets
As a statement string read from the relay log on a replication slave (as of MySQL 5.6.13)
The details for a request are not initially known and the Performance Schema proceeds from abstract to specific instrument names in a sequence that depends on the source of the request.
For a request received from a client:
When the server detects a new packet at the socket level, a
new statement is started with an abstract instrument name of
statement/abstract/new_packet.
When the server reads the packet number, it knows more about
the type of request received, and the Performance Schema
refines the instrument name. For example, if the request is
a COM_PING packet, the instrument name
becomes statement/com/Ping and that is
the final name. If the request is a
COM_QUERY packet, it is known to
correspond to an SQL statement but not the particular type
of statement. In this case, the instrument changes from one
abstract name to a more specific but still abstract name,
statement/abstract/Query, and the request
requires further classification.
If the request is a statement, the statement text is read
and given to the parser. After parsing, the exact statement
type is known. If the request is, for example, an
INSERT statement, the
Performance Schema refines the instrument name from
statement/abstract/Query to
statement/sql/insert, which is the final
name.
For a request read as a statement from the relay log on a replication slave:
Statements in the relay log are stored as text and are read
as such. There is no network protocol, so the
statement/abstract/new_packet instrument
is not used. Instead, the initial instrument is
statement/abstract/relay_log.
When the statement is parsed, the exact statement type is
known. If the request is, for example, an
INSERT statement, the
Performance Schema refines the instrument name from
statement/abstract/Query to
statement/sql/insert, which is the final
name.
The preceding description applies only for statement-based replication. For row-based replication, table I/O done on the slave as it processes row changes can be instrumented, but row events in the relay log do not appear as discrete statements.
For statistics to be collected for statements, it is not
sufficient to enable only the final
statement/sql/* instruments used for
individual statement types. The abtract
statement/abstract/* instruments must be
enabled as well. This should not normally be an issue because
all statement instruments are enabled by default. However, an
application that enables or disables statement instruments
selectively must take into account that disabling abstract
instruments also disables statistics collection for the
individual statement instruments. For example, to collect
statistics for INSERT statements,
statement/sql/insert must be enabled, but
also statement/abstract/new_packet and
statement/abstract/Query. Similarly, for
replicated statements to be instrumented,
statement/abstract/relay_log must be enabled.
No statistics are aggregated for abstract instruments such as
statement/abstract/Query because no statement
is ever classified with an abstract instrument as the final
statement name.
The abstract instrument names in the preceding discussion are as of MySQL 5.6.15. In earlier 5.6 versions, there was some renaming before those names were settled on:
statement/abstract/new_packet was
statement/com/ in MySQL 5.6.14,
statement/com/new_packet in MySQL 5.6.13,
and statement/com/ before that.
statement/abstract/Query was
statement/com/Query before MySQL 5.6.15.
statement/abstract/relay_log was
statement/rpl/relay_log from MySQL 5.6.13
to 5.6.14 and did not exist before that.
The events_statements_current
table contains current statement events, one row per thread
showing the current status of the thread's most recent
monitored statement event.
The events_statements_current
table can be truncated with TRUNCATE
TABLE.
Of the tables that contain statement event rows,
events_statements_current is the
most fundamental. Other tables that contain statement event
rows are logically derived from the current events. For
example, the
events_statements_history and
events_statements_history_long
tables are collections of the most recent statement events, up
to a fixed number of rows.
For information about configuration of statement event collection, see Section 8.6, “Performance Schema Statement Event Tables”.
The events_statements_current
table has these columns:
THREAD_ID, EVENT_ID
The thread associated with the event and the thread
current event number when the event starts. The
THREAD_ID and
EVENT_ID values taken together form a
primary key that uniquely identifies the row. No two rows
will have the same pair of values.
END_EVENT_ID
This column is set to NULL when the
event starts and updated to the thread current event
number when the event ends. This column was added in MySQL
5.6.4.
EVENT_NAME
The name of the instrument from which the event was
collected. This is a NAME value from
the setup_instruments table.
Instrument names may have multiple parts and form a
hierarchy, as discussed in
Chapter 5, Performance Schema Instrument Naming Conventions.
For SQL statements, the EVENT_NAME
value initially is statement/com/Query
until the statement is parsed, then changes to a more
appropriate value, as described in
Section 8.6, “Performance Schema Statement Event Tables”.
SOURCE
The name of the source file containing the instrumented code that produced the event and the line number in the file at which the instrumentation occurs. This enables you to check the source to determine exactly what code is involved.
TIMER_START,
TIMER_END,
TIMER_WAIT
Timing information for the event. The unit for these
values is picoseconds (trillionths of a second). The
TIMER_START and
TIMER_END values indicate when event
timing started and ended. TIMER_WAIT is
the event elapsed time (duration).
If an event has not finished, TIMER_END
and TIMER_WAIT are
NULL before MySQL 5.6.26. As of 5.6.26,
TIMER_END is the current timer value
and TIMER_WAIT is the time elapsed so
far (TIMER_END −
TIMER_START).
If an event is produced from an instrument that has
TIMED = NO, timing information is not
collected, and TIMER_START,
TIMER_END, and
TIMER_WAIT are all
NULL.
For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 3.3.1, “Performance Schema Event Timing”.
LOCK_TIME
The time spent waiting for table locks. This value is computed in microseconds but normalized to picoseconds for easier comparison with other Performance Schema timers.
SQL_TEXT
The text of the SQL statement. For a command not
associated with an SQL statement, the value is
NULL. The maximum space available for
statement display is 1024 bytes.
DIGEST
The statement digest MD5 value as a string of 32
hexadecimal characters, or NULL if the
statement_digest consumer is
no. For more information about
statement digesting, see
Performance Schema Statement Digests.
This column was added in MySQL 5.6.5.
DIGEST_TEXT
The normalized statement digest text, or
NULL if the
statement_digest consumer is
no. For more information about
statement digesting, see
Performance Schema Statement Digests.
This column was added in MySQL 5.6.5.
CURRENT_SCHEMA
The default database for the statement,
NULL if there is none.
OBJECT_SCHEMA,
OBJECT_NAME,
OBJECT_TYPE
Reserved. Always NULL.
OBJECT_INSTANCE_BEGIN
This column identifies the statement. The value is the address of an object in memory.
MYSQL_ERRNO
The statement error number, from the statement diagnostics area.
RETURNED_SQLSTATE
The statement SQLSTATE value, from the statement diagnostics area.
MESSAGE_TEXT
The statement error message, from the statement diagnostics area.
ERRORS
Whether an error occurred for the statement. The value is
0 if the SQLSTATE value begins with 00
(completion) or 01 (warning). The value
is 1 is the SQLSTATE value is anything else.
WARNINGS
The number of warnings, from the statement diagnostics area.
ROWS_AFFECTED
The number of rows affected by the statement. For a description of the meaning of “affected,” see mysql_affected_rows().
ROWS_SENT
The number of rows returned by the statement.
ROWS_EXAMINED
The number of rows read from storage engines during statement execution.
CREATED_TMP_DISK_TABLES
Like the
Created_tmp_disk_tables
status variable, but specific to the statement.
CREATED_TMP_TABLES
Like the
Created_tmp_tables
status variable, but specific to the statement.
SELECT_FULL_JOIN
Like the
Select_full_join status
variable, but specific to the statement.
SELECT_FULL_RANGE_JOIN
Like the
Select_full_range_join
status variable, but specific to the statement.
SELECT_RANGE
Like the Select_range
status variable, but specific to the statement.
SELECT_RANGE_CHECK
Like the
Select_range_check
status variable, but specific to the statement.
SELECT_SCAN
Like the Select_scan
status variable, but specific to the statement.
SORT_MERGE_PASSES
Like the
Sort_merge_passes status
variable, but specific to the statement.
SORT_RANGE
Like the Sort_range
status variable, but specific to the statement.
SORT_ROWS
Like the Sort_rows
status variable, but specific to the statement.
SORT_SCAN
Like the Sort_scan
status variable, but specific to the statement.
NO_INDEX_USED
1 if the statement performed a table scan without using an index, 0 otherwise.
NO_GOOD_INDEX_USED
1 if the server found no good index to use for the
statement, 0 otherwise. For additional information, see
the description of the Extra column
from EXPLAIN output for the
Range checked for each record value in
EXPLAIN Output Format.
NESTING_EVENT_ID,
NESTING_EVENT_TYPE
Reserved. Always NULL.
The events_statements_current
table was added in MySQL 5.6.3.
The events_statements_history
table contains the most recent N
statement events per thread. The value of
N is autosized at server startup.
To set the table size explicitly, set the
performance_schema_events_statements_history_size
system variable at server startup. Statement events are not
added to the table until they have ended. As new events are
added, older events are discarded if the table is full.
The events_statements_history
table has the same structure as
events_statements_current. See
Section 8.6.1, “The events_statements_current Table”.
The events_statements_history
table can be truncated with TRUNCATE
TABLE.
The events_statements_history
table was added in MySQL 5.6.3.
For information about configuration of statement event collection, see Section 8.6, “Performance Schema Statement Event Tables”.
The
events_statements_history_long
table contains the most recent N
statement events. The value of N is
autosized at server startup. To set the table size explicitly,
set the
performance_schema_events_statements_history_long_size
system variable at server startup. Statement events are not
added to the table until they have ended. As new events are
added, older events are discarded if the table is full. When a
thread ends, its rows are removed from the table.
The
events_statements_history_long
table has the same structure as
events_statements_current. See
Section 8.6.1, “The events_statements_current Table”.
The
events_statements_history_long
table can be truncated with TRUNCATE
TABLE.
The
events_statements_history_long
table was added in MySQL 5.6.3.
For information about configuration of statement event collection, see Section 8.6, “Performance Schema Statement Event Tables”.
As of MySQL 5.6.3, the Performance Schema provides statistics about connections to the server. When a client connects, it does so under a particular user name and from a particular host. The Performance Schema tracks connections per account (user name plus host name) and separately per user name and per host name, using these tables:
There are also summary tables that aggregate information about connections. See Section 8.9.7, “Connection Summary Tables”.
The meaning of “account” in the connection tables
is similar to its meaning in the MySQL grant tables in the
mysql database, in the sense that the term
refers to a combination of user and host values. Where they
differ is that in the grant tables, the host part of an account
can be a pattern, whereas in the Performance Schema tables the
host value is always a specific nonpattern host name.
The connection tables all have
CURRENT_CONNECTIONS and
TOTAL_CONNECTIONS columns to track the
current and total number of connections per “tracking
value” on which statistics are based. The tables differ
in what they use for the tracking value. The
accounts table has
USER and HOST columns to
track connections per user name plus host name combination. The
users and
hosts tables have a
USER and HOST column,
respectively, to track connections per user name and per host
name.
Suppose that clients named user1 and
user2 each connect one time from
hosta and hostb. The
Performance Schema tracks the connections as follows:
The accounts table will have
four rows, for the
user1/hosta,
user1/hostb,
user2/hosta, and
user2/hostb account
values, each row counting one connection per account.
The users table will have two
rows, for user1 and
user2, each row counting two connections
per user name.
The hosts table will have two
rows, for hosta and
hostb, each row counting two connections
per host name.
When a client connects, the Performance Schema determines which
row in each connection table applies to the connection, using
the tracking value appropriate to each table. If there is no
such row, one is added. Then the Performance Schema increments
by one the CURRENT_CONNECTIONS and
TOTAL_CONNECTIONS columns in that row.
When a client disconnects, the Performance Schema decrements by
one the CURRENT_CONNECTIONS column in the row
and leaves the TOTAL_CONNECTIONS column
unchanged.
The Performance Schema also counts internal threads and threads
for user sessions that failed to authenticate. These are counted
in rows with USER and HOST
column values of NULL.
Each connection table can be truncated with
TRUNCATE TABLE, which has this
effect:
Rows with CURRENT_CONNECTIONS = 0 are
deleted.
For rows with CURRENT_CONNECTIONS > 0,
TOTAL_CONNECTIONS is reset to
CURRENT_CONNECTIONS.
Connection summary tables that depend on the connection table are truncated implicitly (summary values are set to 0). For more information about implicit truncation, see Section 8.9.7, “Connection Summary Tables”.
The accounts table contains a row
for each account that has connected to the MySQL server. For
each account, the table counts the current and total number of
connections. The table size is autosized at server startup. To
set the table size explicitly, set the
performance_schema_accounts_size
system variable at server startup. To disable account
statistics, set this variable to 0.
The accounts table has the
following columns. For a description of how the Performance
Schema maintains rows in this table, including the effect of
TRUNCATE TABLE, see
Section 8.7, “Performance Schema Connection Tables”.
USER
The client user name for the connection. This is
NULL for an internal thread, or for a
user session that failed to authenticate.
The
performance_schema_max_digest_length
system variable determines the maximum number of bytes
available for computing statement digests. However, the
display length of statement digests may be longer than the
available buffer size due to encoding of statement
components such as keywords and literal values in digest
buffer. Consequently, values selected from the
DIGEST_TEXT column of statement event
tables may appear to exceed the
performance_schema_max_digest_length
value.
This variable was added in MySQL 5.6.26.
max_digest_length. In
MySQL 5.6.24 and 5.6.25, use
max_digest_length
instead. Before 5.6.24, the value cannot be changed.
HOST
The host from which the client connected. This is
NULL for an internal thread, or for a
user session that failed to authenticate.
CURRENT_CONNECTIONS
The current number of connections for the account.
TOTAL_CONNECTIONS
The total number of connections for the account.
The accounts table was added in
MySQL 5.6.3.
The hosts table contains a row
for each host from which clients have connected to the MySQL
server. For each host name, the table counts the current and
total number of connections. The table size is autosized at
server startup. To set the table size explicitly, set the
performance_schema_hosts_size
system variable at server startup. To disable host statistics,
set this variable to 0.
The hosts table has the following
columns. For a description of how the Performance Schema
maintains rows in this table, including the effect of
TRUNCATE TABLE, see
Section 8.7, “Performance Schema Connection Tables”.
HOST
The host from which the client connected. This is
NULL for an internal thread, or for a
user session that failed to authenticate.
CURRENT_CONNECTIONS
The current number of connections for the host.
TOTAL_CONNECTIONS
The total number of connections for the host.
The hosts table was added in
MySQL 5.6.3.
The users table contains a row
for each user who has connected to the MySQL server. For each
user name, the table counts the current and total number of
connections. The table size is autosized at server startup. To
set the table size explicitly, set the
performance_schema_users_size
system variable at server startup. To disable user statistics,
set this variable to 0.
The users table has the following
columns. For a description of how the Performance Schema
maintains rows in this table, including the effect of
TRUNCATE TABLE, see
Section 8.7, “Performance Schema Connection Tables”.
USER
The client user name for the connection. This is
NULL for an internal thread, or for a
user session that failed to authenticate.
CURRENT_CONNECTIONS
The current number of connections for the user.
TOTAL_CONNECTIONS
The total number of connections for the user.
The users table was added in
MySQL 5.6.3.
As of MySQL 5.6.6, application programs can provide key/value
pairs as connection attributes to be passed to the server at at
connect time. For the C API, define the attribute set using the
mysql_options() and
mysql_options4() functions.
Other MySQL Connectors may provide their own
attribute-definition methods.
These tables expose attribute information:
session_account_connect_attrs:
Connection attributes for the current session, and other
sessions associated with the session account
session_connect_attrs:
Connection attributes for all sessions
Attribute names that begin with an underscore
(_) are reserved for internal use and should
not be created by application programs. This convention permits
new attributes to be introduced by MySQL without colliding with
application attributes.
The set of connection attributes visible on a given connection varies depending on your platform and MySQL Connector used to establish the connection.
The libmysqlclient client library (provided
in MySQL and MySQL Connector/C distributions) sets these attributes:
_client_name: The client name
(libmysql for the client library)
_client_version: The client library
version
_os: The operating system (for example,
Linux, Win64)
_pid: The client process ID
_platform: The machine platform (for
example, x86_64)
_thread: The client thread ID (Windows
only)
Other MySQL Connectors may define their own connection attributes.
MySQL Connector/J defines these attributes:
_client_license: The connector license
type
_runtime_vendor: The Java runtime
environment (JRE) vendor
_runtime_version: The Java runtime
environment (JRE) version
MySQL Connector/Net defines these attributes:
_client_version: The client library
version
_os: The operating system (for example,
Linux, Win64)
_pid: The client process ID
_platform: The machine platform (for
example, x86_64)
_program_name: The client name
_thread: The client thread ID (Windows
only)
PHP defines attributes that depend on how it was compiled:
Compiled using libmysqlclient: The
standard libmysqlclient attributes,
described previously
Compiled using mysqlnd: Only the
_client_name attribute, with a value of
mysqlnd
Many MySQL client programs set a program_name
attribute with a value equal to the client name. For example,
mysqladmin and mysqldump
set program_name to
mysqladmin and mysqldump,
respectively.
Some MySQL clients define additional attributes:
mysqlbinlog defines the
_client_role attribute as
binary_log_listener.
Replication slave connections define
program_name as mysqld
and _client_role as
binary_log_listener.
FEDERATED storage engine
connections define program_name as
mysqld and
_client_role as
federated_storage.
There are limits on the amount of connection attribute data transmitted from client to server: A fixed limit imposed by the client prior to connect time; a fixed limit imposed by the server at connect time; and a configurable limit imposed by the Performance Schema at connect time.
For connections initiated using the C API, the
libmysqlclient library imposes a limit of
64KB on the aggregate size of connection attribute data on the
client side: Calls to
mysql_options() that cause this
limit to be exceeded produce a
CR_INVALID_PARAMETER_NO error.
Other MySQL Connectors may impose their own client-side limits
on how much connection attribute data can be transmitted to the
server.
On the server side, these size checks on connection attribute data occur:
The server imposes a limit of 64KB on the aggregate size of connection attribute data it will accept. If a client attempts to send more than 64KB of attribute data, the server rejects the connection.
For accepted connections, the Performance Schema checks
aggregate attribute size against the value of the
performance_schema_session_connect_attrs_size
system variable. If attribute size exceeds this value, these
actions take place:
The Performance Schema truncates the attribute data and
increments the
Performance_schema_session_connect_attrs_lost
status variable, which indicates the number of
connections for which attribute truncation occurred.
The Performance Schema writes a message to the error log
if the log_warnings
system variable is greater than zero:
[Warning] Connection attributes of length N were truncated
As of MySQL 5.6.6, application programs can provide key/value
connection attributes to be passed to the server at connect
time, using the
mysql_options() and
mysql_options4() C API
functions.
The session_account_connect_attrs
table contains connection attributes only for sessions open
for your own account. To see connection attributes for all
sessions, look in the
session_connect_attrs table. For
descriptions of common attributes, see
Section 8.8, “Performance Schema Connection Attribute Tables”.
The session_account_connect_attrs
table contains these columns:
PROCESSLIST_ID
The connection identifier for the session.
ATTR_NAME
The attribute name.
ATTR_VALUE
The attribute value.
ORDINAL_POSITION
The order in which the attribute was added to the set of connection attributes.
As of MySQL 5.6.6, application programs can provide key/value
connection attributes to be passed to the server at connect
time, using the
mysql_options() and
mysql_options4() C API
functions. For descriptions of common attributes, see
Section 8.8, “Performance Schema Connection Attribute Tables”.
The session_connect_attrs table
contains connection attributes for all sessions. To see
connection attributes only for sessions open for your own
account, look in the
session_account_connect_attrs
table.
The session_connect_attrs table
contains these columns:
PROCESSLIST_ID
The connection identifier for the session.
ATTR_NAME
The attribute name.
ATTR_VALUE
The attribute value.
ORDINAL_POSITION
The order in which the attribute was added to the set of connection attributes.
Summary tables provide aggregated information for terminated events over time. The tables in this group summarize event data in different ways.
Event Wait Summaries:
events_waits_summary_global_by_event_name:
Wait events summarized per event name
events_waits_summary_by_instance:
Wait events summarized per instance
events_waits_summary_by_thread_by_event_name:
Wait events summarized per thread and event name
Stage Summaries:
events_stages_summary_by_thread_by_event_name:
Stage waits summarized per thread and event name
events_stages_summary_global_by_event_name:
Stage waits summarized per event name
Statement Summaries:
events_statements_summary_by_digest:
Statement events summarized per schema and digest value
events_statements_summary_by_thread_by_event_name:
Statement events summarized per thread and event name
events_statements_summary_global_by_event_name:
Statement events summarized per event name
Object Wait Summaries:
objects_summary_global_by_type:
Object summaries
File I/O Summaries:
file_summary_by_event_name:
File events summarized per event name
file_summary_by_instance: File
events summarized per file instance
Table I/O and Lock Wait Summaries:
table_io_waits_summary_by_index_usage:
Table I/O waits per index
table_io_waits_summary_by_table:
Table I/O waits per table
table_lock_waits_summary_by_table:
Table lock waits per table
Connection Summaries:
events_waits_summary_by_account_by_event_name:
Wait events summarized per account and event name
events_waits_summary_by_user_by_event_name:
Wait events summarized per user name and event name
events_waits_summary_by_host_by_event_name:
Wait events summarized per host name and event name
events_stages_summary_by_account_by_event_name:
Stage events summarized per account and event name
events_stages_summary_by_user_by_event_name:
Stage events summarized per user name and event name
events_stages_summary_by_host_by_event_name:
Stage events summarized per host name and event name
events_statements_summary_by_digest:
Statement events summarized per schema and digest value
events_statements_summary_by_account_by_event_name:
Statement events summarized per account and event name
events_statements_summary_by_user_by_event_name:
Statement events summarized per user name and event name
events_statements_summary_by_host_by_event_name:
Statement events summarized per host name and event name
Socket Summaries:
socket_summary_by_instance:
Socket waits and I/O summarized per instance
socket_summary_by_event_name:
Socket waits and I/O summarized per event name
Each summary table has grouping columns that determine how to group the data to be aggregated, and summary columns that contain the aggregated values. Tables that summarize events in similar ways often have similar sets of summary columns and differ only in the grouping columns used to determine how events are aggregated.
Summary tables can be truncated with
TRUNCATE TABLE. Except for
events_statements_summary_by_digest,
the effect is to reset the summary columns to 0 or
NULL, not to remove rows. This enables you to
clear collected values and restart aggregation. That might be
useful, for example, after you have made a runtime configuration
change.
The Performance Schema maintains tables for collecting current and recent wait events, and aggregates that information in summary tables. Section 8.4, “Performance Schema Wait Event Tables” describes the events on which wait summaries are based. See that discussion for information about the content of wait events, the current and recent wait event tables, and how to control wait event collection.
Each event waits summary table has one or more grouping
columns to indicate how the table aggregates events. Event
names refer to names of event instruments in the
setup_instruments table.
events_waits_summary_global_by_event_name
has an EVENT_NAME column. Each row
summarizes events for a given event name. An instrument
might be used to create multiple instances of the
instrumented object. For example, if there is an
instrument for a mutex that is created for each
connection, there are as many instances as there are
connections. The summary row for the instrument summarizes
over all these instances.
events_waits_summary_by_instance
has EVENT_NAME and
OBJECT_INSTANCE_BEGIN columns. Each row
summarizes events for a given event name and object. If an
instrument is used to create multiple instances, each
instance has a unique
OBJECT_INSTANCE_BEGIN value, so these
instances are summarized separately in this table.
events_waits_summary_by_thread_by_event_name
has THREAD_ID and
EVENT_NAME columns. Each row summarizes
events for a given thread and event name.
Each event waits summary table has these summary columns containing aggregated values:
COUNT_STAR
The number of summarized events. This value includes all events, whether timed or nontimed.
SUM_TIMER_WAIT
The total wait time of the summarized timed events. This
value is calculated only for timed events because nontimed
events have a wait time of NULL. The
same is true for the other
xxx_TIMER_WAIT
MIN_TIMER_WAIT
The minimum wait time of the summarized timed events.
AVG_TIMER_WAIT
The average wait time of the summarized timed events.
MAX_TIMER_WAIT
The maximum wait time of the summarized timed events.
Example wait event summary information:
mysql> SELECT * FROM events_waits_summary_global_by_event_name\G
...
*************************** 6. row ***************************
EVENT_NAME: wait/synch/mutex/sql/BINARY_LOG::LOCK_index
COUNT_STAR: 8
SUM_TIMER_WAIT: 2119302
MIN_TIMER_WAIT: 196092
AVG_TIMER_WAIT: 264912
MAX_TIMER_WAIT: 569421
...
*************************** 9. row ***************************
EVENT_NAME: wait/synch/mutex/sql/hash_filo::lock
COUNT_STAR: 69
SUM_TIMER_WAIT: 16848828
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 244185
MAX_TIMER_WAIT: 735345
...
TRUNCATE TABLE is permitted for
wait summary tables. It resets the summary columns to zero
rather than removing rows.
As of MySQL 5.6.3, the Performance Schema maintains tables for collecting current and recent stage events, and aggregates that information in summary tables. Section 8.5, “Performance Schema Stage Event Tables” describes the events on which stage summaries are based. See that discussion for information about the content of stage events, the current and recent stage event tables, and how to control stage event collection.
Each stage summary table has one or more grouping columns to
indicate how the table aggregates events. Event names refer to
names of event instruments in the
setup_instruments table.
events_stages_summary_by_thread_by_event_name
has THREAD_ID and
EVENT_NAME columns. Each row summarizes
events for a given thread and event name.
events_stages_summary_global_by_event_name
has an EVENT_NAME column. Each row
summarizes events for a given event name.
Each stage summary table has these summary columns containing
aggregated values: COUNT_STAR,
SUM_TIMER_WAIT,
MIN_TIMER_WAIT,
AVG_TIMER_WAIT, and
MAX_TIMER_WAIT. These columns are analogous
to the columns of the same names in the event wait summary
tables (see Section 8.9.1, “Event Wait Summary Tables”), except
that the stage summary tables aggregate waits from
events_stages_current rather than
events_waits_current.
Example stage event summary information:
mysql> SELECT * FROM events_stages_summary_global_by_event_name\G
...
*************************** 5. row ***************************
EVENT_NAME: stage/sql/checking permissions
COUNT_STAR: 57
SUM_TIMER_WAIT: 26501888880
MIN_TIMER_WAIT: 7317456
AVG_TIMER_WAIT: 464945295
MAX_TIMER_WAIT: 12858936792
...
*************************** 9. row ***************************
EVENT_NAME: stage/sql/closing tables
COUNT_STAR: 37
SUM_TIMER_WAIT: 662606568
MIN_TIMER_WAIT: 1593864
AVG_TIMER_WAIT: 17907891
MAX_TIMER_WAIT: 437977248
...
TRUNCATE TABLE is permitted for
stage summary tables. It resets the summary columns to zero
rather than removing rows.
As of MySQL 5.6.3, the Performance Schema maintains tables for collecting current and recent statement events, and aggregates that information in summary tables. Section 8.6, “Performance Schema Statement Event Tables” describes the events on which statement summaries are based. See that discussion for information about the content of statement events, the current and recent statement event tables, and how to control statement event collection.
Each statement summary table has one or more grouping columns
to indicate how the table aggregates events. Event names refer
to names of event instruments in the
setup_instruments table.
events_statements_summary_by_digest
has SCHEMA_NAME and
DIGEST columns. Each row summarizes
events for given schema/digest values. (The
DIGEST_TEXT column contains the
corresponding normalized statement digest text, but is
neither a grouping nor summary column.)
This table was added in 5.6.5. Before MySQL 5.6.9, there
is no SCHEMA_NAME column and grouping
is based on DIGEST values only.
events_statements_summary_by_thread_by_event_name
has THREAD_ID and
EVENT_NAME columns. Each row summarizes
events for a given thread and event name.
events_statements_summary_global_by_event_name
has an EVENT_NAME column. Each row
summarizes events for a given event name.
Each statement summary table has these summary columns containing aggregated values:
COUNT_STAR,
SUM_TIMER_WAIT,
MIN_TIMER_WAIT,
AVG_TIMER_WAIT,
MAX_TIMER_WAIT
These columns are analogous to the columns of the same
names in the event wait summary tables (see
Section 8.9.1, “Event Wait Summary Tables”), except that the
statement summary tables aggregate events from
events_statements_current
rather than
events_waits_current.
SUM_
xxx
The aggregate of the corresponding
xxx column in the
events_statements_current
table. For example, the SUM_LOCK_TIME
and SUM_ERRORS columns in statement
summary tables are the aggregates of the
LOCK_TIME and ERRORS
columns in
events_statements_current
table.
The
events_statements_summary_by_digest
table has these additional summary columns:
FIRST_SEEN_TIMESTAMP,
LAST_SEEN_TIMESTAMP
The times at which a statement with the given digest value were first seen and most recently seen.
Example statement event summary information:
mysql> SELECT * FROM events_statements_summary_global_by_event_name\G
*************************** 1. row ***************************
EVENT_NAME: statement/sql/select
COUNT_STAR: 25
SUM_TIMER_WAIT: 1535983999000
MIN_TIMER_WAIT: 209823000
AVG_TIMER_WAIT: 61439359000
MAX_TIMER_WAIT: 1363397650000
SUM_LOCK_TIME: 20186000000
SUM_ERRORS: 0
SUM_WARNINGS: 0
SUM_ROWS_AFFECTED: 0
SUM_ROWS_SENT: 388
SUM_ROWS_EXAMINED: 370
SUM_CREATED_TMP_DISK_TABLES: 0
SUM_CREATED_TMP_TABLES: 0
SUM_SELECT_FULL_JOIN: 0
SUM_SELECT_FULL_RANGE_JOIN: 0
SUM_SELECT_RANGE: 0
SUM_SELECT_RANGE_CHECK: 0
SUM_SELECT_SCAN: 6
SUM_SORT_MERGE_PASSES: 0
SUM_SORT_RANGE: 0
SUM_SORT_ROWS: 0
SUM_SORT_SCAN: 0
SUM_NO_INDEX_USED: 6
SUM_NO_GOOD_INDEX_USED: 0
...
TRUNCATE TABLE is permitted for
statement summary tables. For
events_statements_summary_by_digest,
it empties the table. For the other statement summary tables,
it resets the summary columns to zero rather than removing
rows.
If the statement_digest consumer is
enabled, aggregation into
events_statements_summary_by_digest
occurs as follows when a statement completes. Aggregation is
based on the DIGEST value computed for the
statement.
If a
events_statements_summary_by_digest
row already exists with the digest value for the statement
that just completed, statistics for the statement are
aggregated to that row. The LAST_SEEN
column is updated to the current time.
If no row has the digest value for the statement that just
completed, and the table is not full, a new row is created
for the statement. The FIRST_SEEN and
LAST_SEEN columns are initialized with
the current time.
If no row has the statement digest value for the statement
that just completed, and the table is full, the statistics
for the statement that just completed are added to a
special “catch-all” row with
DIGEST = NULL, which
is created if necessary. If the row is created, the
FIRST_SEEN and
LAST_SEEN columns are initialized with
the current time. Otherwise, the
LAST_SEEN column is updated with the
current time.
The row with DIGEST =
NULL is maintained because Performance
Schema tables have a maximum size due to memory constraints.
The DIGEST = NULL row
permits digests that do not match other rows to be counted
even if the summary table is full, using a common
“other” bucket. This row helps you estimate
whether the digest summary is representative:
A DIGEST = NULL row
that has a COUNT_STAR value that
represents 5% of all digests shows that the digest summary
table is very representative; the other rows cover 95% of
the statements seen.
A DIGEST = NULL row
that has a COUNT_STAR value that
represents 50% of all digests shows that the digest
summary table is not very representative; the other rows
cover only half the statements seen. Most likely the DBA
should increase the maximum table size so that more of the
rows counted in the DIGEST =
NULL row would be counted using more
specific rows instead. To do this, set the
performance_schema_digests_size
system variable to a larger value at server startup. The
default size is 200.
The
objects_summary_global_by_type
table aggregates object wait events. It has these grouping
columns to indicate how the table aggregates events:
OBJECT_TYPE,
OBJECT_SCHEMA, and
OBJECT_NAME. Each row summarizes events for
the given object.
objects_summary_global_by_type
has the same summary columns as the
events_waits_summary_by_
tables. See Section 8.9.1, “Event Wait Summary Tables”.
xxx
Example object wait event summary information:
mysql> SELECT * FROM objects_summary_global_by_type\G
...
*************************** 3. row ***************************
OBJECT_TYPE: TABLE
OBJECT_SCHEMA: test
OBJECT_NAME: t
COUNT_STAR: 3
SUM_TIMER_WAIT: 263126976
MIN_TIMER_WAIT: 1522272
AVG_TIMER_WAIT: 87708678
MAX_TIMER_WAIT: 258428280
...
*************************** 10. row ***************************
OBJECT_TYPE: TABLE
OBJECT_SCHEMA: mysql
OBJECT_NAME: user
COUNT_STAR: 14
SUM_TIMER_WAIT: 365567592
MIN_TIMER_WAIT: 1141704
AVG_TIMER_WAIT: 26111769
MAX_TIMER_WAIT: 334783032
...
TRUNCATE TABLE is permitted for
the object summary table. It resets the summary columns to
zero rather than removing rows.
The file I/O summary tables aggregate information about I/O operations.
Each file I/O summary table has one or more grouping columns
to indicate how the table aggregates events. Event names refer
to names of event instruments in the
setup_instruments table.
file_summary_by_event_name
has an EVENT_NAME column. Each row
summarizes events for a given event name.
file_summary_by_instance has
FILE_NAME,
EVENT_NAME, and (as of MySQL 5.6.4)
OBJECT_INSTANCE_BEGIN columns. Each row
summarizes events for a given file and event name.
Each file I/O summary table has the following summary columns
containing aggregated values. (Before MySQL 5.6.4, the tables
contain only the COUNT_READ
COUNT_WRITE
SUM_NUMBER_OF_BYTES_READ, and
SUM_NUMBER_OF_BYTES_WRITE aggregation
columns.) Some columns are more general and have values that
are the same as the sum of the values of more fine-grained
columns. In this way, aggregations at higher levels are
available directly without the need for user-defined views
that sum lower-level columns.
COUNT_STAR,
SUM_TIMER_WAIT,
MIN_TIMER_WAIT,
AVG_TIMER_WAIT,
MAX_TIMER_WAIT
These columns aggregate all I/O operations.
COUNT_READ,
SUM_TIMER_READ,
MIN_TIMER_READ,
AVG_TIMER_READ,
MAX_TIMER_READ,
SUM_NUMBER_OF_BYTES_READ
These columns aggregate all read operations, including
FGETS, FGETC,
FREAD, and READ.
COUNT_WRITE,
SUM_TIMER_WRITE,
MIN_TIMER_WRITE,
AVG_TIMER_WRITE,
MAX_TIMER_WRITE,
SUM_NUMBER_OF_BYTES_WRITE
These columns aggregate all write operations, including
FPUTS, FPUTC,
FPRINTF, VFPRINTF,
FWRITE, and PWRITE.
COUNT_MISC,
SUM_TIMER_MISC,
MIN_TIMER_MISC,
AVG_TIMER_MISC,
MAX_TIMER_MISC
These columns aggregate all other I/O operations,
including CREATE,
DELETE, OPEN,
CLOSE, STREAM_OPEN,
STREAM_CLOSE, SEEK,
TELL, FLUSH,
STAT, FSTAT,
CHSIZE, RENAME, and
SYNC. There are no byte counts for
these operations.
Example file I/O event summary information:
mysql>SELECT * FROM file_summary_by_event_name\G... *************************** 2. row *************************** EVENT_NAME: wait/io/file/sql/binlog COUNT_STAR: 31 SUM_TIMER_WAIT: 8243784888 MIN_TIMER_WAIT: 0 AVG_TIMER_WAIT: 265928484 MAX_TIMER_WAIT: 6490658832 ... mysql>SELECT * FROM file_summary_by_instance\G... *************************** 2. row *************************** FILE_NAME: /var/mysql/share/english/errmsg.sys EVENT_NAME: wait/io/file/sql/ERRMSG EVENT_NAME: wait/io/file/sql/ERRMSG OBJECT_INSTANCE_BEGIN: 4686193384 COUNT_STAR: 5 SUM_TIMER_WAIT: 13990154448 MIN_TIMER_WAIT: 26349624 AVG_TIMER_WAIT: 2798030607 MAX_TIMER_WAIT: 8150662536 ...
TRUNCATE TABLE is permitted for
file I/O summary tables. It resets the summary columns to zero
rather than removing rows.
The MySQL server uses several techniques to avoid I/O operations by caching information read from files, so it is possible that statements you might expect to result in I/O events will not. You may be able to ensure that I/O does occur by flushing caches or restarting the server to reset its state.
The following sections describe the table I/O and lock wait summary tables:
table_io_waits_summary_by_index_usage:
Table I/O waits per index
table_io_waits_summary_by_table:
Table I/O waits per table
table_lock_waits_summary_by_table:
Table lock waits per table
The
table_io_waits_summary_by_table
table aggregates all table I/O wait events, as generated by
the wait/io/table/sql/handler instrument.
The grouping is by table.
The
table_io_waits_summary_by_table
table has these grouping columns to indicate how the table
aggregates events: OBJECT_TYPE,
OBJECT_SCHEMA, and
OBJECT_NAME. These columns have the same
meaning as in the
events_waits_current table.
They identify the table to which the row applies.
table_io_waits_summary_by_table
has the following summary columns containing aggregated
values. As indicated in the column descriptions, some
columns are more general and have values that are the same
as the sum of the values of more fine-grained columns. For
example, columns that aggregate all writes hold the sum of
the corresponding columns that aggregate inserts, updates,
and deletes. In this way, aggregations at higher levels are
available directly without the need for user-defined views
that sum lower-level columns.
COUNT_STAR,
SUM_TIMER_WAIT,
MIN_TIMER_WAIT,
AVG_TIMER_WAIT,
MAX_TIMER_WAIT
These columns aggregate all I/O operations. They are the
same as the sum of the corresponding
xxx_READxxx_WRITE
COUNT_READ,
SUM_TIMER_READ,
MIN_TIMER_READ,
AVG_TIMER_READ,
MAX_TIMER_READ
These columns aggregate all read operations. They are
the same as the sum of the corresponding
xxx_FETCH
COUNT_WRITE,
SUM_TIMER_WRITE,
MIN_TIMER_WRITE,
AVG_TIMER_WRITE,
MAX_TIMER_WRITE
These columns aggregate all write operations. They are
the same as the sum of the corresponding
xxx_INSERTxxx_UPDATExxx_DELETE
COUNT_FETCH,
SUM_TIMER_FETCH,
MIN_TIMER_FETCH,
AVG_TIMER_FETCH,
MAX_TIMER_FETCH
These columns aggregate all fetch operations.
COUNT_INSERT,
SUM_TIMER_INSERT,
MIN_TIMER_INSERT,
AVG_TIMER_INSERT,
MAX_TIMER_INSERT
These columns aggregate all insert operations.
COUNT_UPDATE,
SUM_TIMER_UPDATE,
MIN_TIMER_UPDATE,
AVG_TIMER_UPDATE,
MAX_TIMER_UPDATE
These columns aggregate all update operations.
COUNT_DELETE,
SUM_TIMER_DELETE,
MIN_TIMER_DELETE,
AVG_TIMER_DELETE,
MAX_TIMER_DELETE
These columns aggregate all delete operations.
TRUNCATE TABLE is permitted
for table I/O summary tables. It resets the summary columns
to zero rather than removing rows. Truncating this table
also truncates the
table_io_waits_summary_by_index_usage
table.
The
table_io_waits_summary_by_index_usage
table aggregates all table index I/O wait events, as
generated by the
wait/io/table/sql/handler instrument. The
grouping is by table index.
The structure of
table_io_waits_summary_by_index_usage
is nearly identical to
table_io_waits_summary_by_table.
The only difference is the additional group column,
INDEX_NAME, which corresponds to the name
of the index that was used when the table I/O wait event was
recorded:
A value of PRIMARY indicates that
table I/O used the primary index.
A value of NULL means that table I/O
used no index.
Inserts are counted against INDEX_NAME =
NULL.
TRUNCATE TABLE is permitted
for table I/O summary tables. It resets the summary columns
to zero rather than removing rows. This table is also
truncated by truncation of the
table_io_waits_summary_by_table
table. A DDL operation that changes the index structure of a
table may cause the per-index statistics to be reset.
The
table_lock_waits_summary_by_table
table aggregates all table lock wait events, as generated by
the wait/lock/table/sql/handler
instrument. The grouping is by table.
This table contains information about internal and external locks:
An internal lock corresponds to a lock in the SQL layer.
This is currently implemented by a call to
thr_lock(). In event rows, these
locks are distinguished by the
OPERATION column, which will have one
of these values:
read normal read with shared locks read high priority read no insert write allow write write concurrent insert write delayed write low priority write normal
An external lock corresponds to a lock in the storage
engine layer. This is currently implemented by a call to
handler::external_lock(). In event
rows, these locks are distinguished by the
OPERATION column, which will have one
of these values:
read external write external
The
table_lock_waits_summary_by_table
table has these grouping columns to indicate how the table
aggregates events: OBJECT_TYPE,
OBJECT_SCHEMA, and
OBJECT_NAME. These columns have the same
meaning as in the
events_waits_current table.
They identify the table to which the row applies.
table_lock_waits_summary_by_table
has the following summary columns containing aggregated
values. As indicated in the column descriptions, some
columns are more general and have values that are the same
as the sum of the values of more fine-grained columns. For
example, columns that aggregate all locks hold the sum of
the corresponding columns that aggregate read and write
locks. In this way, aggregations at higher levels are
available directly without the need for user-defined views
that sum lower-level columns.
COUNT_STAR,
SUM_TIMER_WAIT,
MIN_TIMER_WAIT,
AVG_TIMER_WAIT,
MAX_TIMER_WAIT
These columns aggregate all lock operations. They are
the same as the sum of the corresponding
xxx_READxxx_WRITE
COUNT_READ,
SUM_TIMER_READ,
MIN_TIMER_READ,
AVG_TIMER_READ,
MAX_TIMER_READ
These columns aggregate all read-lock operations. They
are the same as the sum of the corresponding
xxx_READ_NORMALxxx_READ_WITH_SHARED_LOCKSxxx_READ_HIGH_PRIORITYxxx_READ_NO_INSERT
COUNT_WRITE,
SUM_TIMER_WRITE,
MIN_TIMER_WRITE,
AVG_TIMER_WRITE,
MAX_TIMER_WRITE
These columns aggregate all write-lock operations. They
are the same as the sum of the corresponding
xxx_WRITE_ALLOW_WRITExxx_WRITE_CONCURRENT_INSERTxxx_WRITE_DELAYEDxxx_WRITE_LOW_PRIORITYxxx_WRITE_NORMAL
COUNT_READ_NORMAL,
SUM_TIMER_READ_NORMAL,
MIN_TIMER_READ_NORMAL,
AVG_TIMER_READ_NORMAL,
MAX_TIMER_READ_NORMAL
These columns aggregate internal read locks.
COUNT_READ_WITH_SHARED_LOCKS,
SUM_TIMER_READ_WITH_SHARED_LOCKS,
MIN_TIMER_READ_WITH_SHARED_LOCKS,
AVG_TIMER_READ_WITH_SHARED_LOCKS,
MAX_TIMER_READ_WITH_SHARED_LOCKS
These columns aggregate internal read locks.
COUNT_READ_HIGH_PRIORITY,
SUM_TIMER_READ_HIGH_PRIORITY,
MIN_TIMER_READ_HIGH_PRIORITY,
AVG_TIMER_READ_HIGH_PRIORITY,
MAX_TIMER_READ_HIGH_PRIORITY
These columns aggregate internal read locks.
COUNT_READ_NO_INSERT,
SUM_TIMER_READ_NO_INSERT,
MIN_TIMER_READ_NO_INSERT,
AVG_TIMER_READ_NO_INSERT,
MAX_TIMER_READ_NO_INSERT
These columns aggregate internal read locks.
COUNT_READ_EXTERNAL,
SUM_TIMER_READ_EXTERNAL,
MIN_TIMER_READ_EXTERNAL,
AVG_TIMER_READ_EXTERNAL,
MAX_TIMER_READ_EXTERNAL
These columns aggregate external read locks.
COUNT_WRITE_ALLOW_WRITE,
SUM_TIMER_WRITE_ALLOW_WRITE,
MIN_TIMER_WRITE_ALLOW_WRITE,
AVG_TIMER_WRITE_ALLOW_WRITE,
MAX_TIMER_WRITE_ALLOW_WRITE
These columns aggregate internal write locks.
COUNT_WRITE_CONCURRENT_INSERT,
SUM_TIMER_WRITE_CONCURRENT_INSERT,
MIN_TIMER_WRITE_CONCURRENT_INSERT,
AVG_TIMER_WRITE_CONCURRENT_INSERT,
MAX_TIMER_WRITE_CONCURRENT_INSERT
These columns aggregate internal write locks.
COUNT_WRITE_DELAYED,
SUM_TIMER_WRITE_DELAYED,
MIN_TIMER_WRITE_DELAYED,
AVG_TIMER_WRITE_DELAYED,
MAX_TIMER_WRITE_DELAYED
These columns aggregate internal write locks.
As of MySQL 5.6.6, DELAYED inserts
are deprecated, so these columns will be removed in a
future release.
COUNT_WRITE_LOW_PRIORITY,
SUM_TIMER_WRITE_LOW_PRIORITY,
MIN_TIMER_WRITE_LOW_PRIORITY,
AVG_TIMER_WRITE_LOW_PRIORITY,
MAX_TIMER_WRITE_LOW_PRIORITY
These columns aggregate internal write locks.
COUNT_WRITE_NORMAL,
SUM_TIMER_WRITE_NORMAL,
MIN_TIMER_WRITE_NORMAL,
AVG_TIMER_WRITE_NORMAL,
MAX_TIMER_WRITE_NORMAL
These columns aggregate internal write locks.
COUNT_WRITE_EXTERNAL,
SUM_TIMER_WRITE_EXTERNAL,
MIN_TIMER_WRITE_EXTERNAL,
AVG_TIMER_WRITE_EXTERNAL,
MAX_TIMER_WRITE_EXTERNAL
These columns aggregate external write locks.
TRUNCATE TABLE is permitted
for table lock summary tables. It resets the summary columns
to zero rather than removing rows.
The connection summary tables are similar to the corresponding
events_
tables, except that aggregation occurs per account, user, or
host, rather than by thread.
xxx_summary_by_thread_by_event_name
The Performance Schema maintains summary tables that aggregate connection statistics by event name and account, user, or host. Separate groups of tables are available that aggregate wait, stage, and statement events, which results in this set of connection summary tables:
events_waits_summary_by_account_by_event_name:
Wait events summarized per account and event name
events_waits_summary_by_user_by_event_name:
Wait events summarized per user name and event name
events_waits_summary_by_host_by_event_name:
Wait events summarized per host name and event name
events_stages_summary_by_account_by_event_name:
Stage events summarized per account and event name
events_stages_summary_by_user_by_event_name:
Stage events summarized per user name and event name
events_stages_summary_by_host_by_event_name:
Stage events summarized per host name and event name
events_statements_summary_by_account_by_event_name:
Statement events summarized per account and event name
events_statements_summary_by_user_by_event_name:
Statement events summarized per user name and event name
events_statements_summary_by_host_by_event_name:
Statement events summarized per host name and event name
In other words, the connection summary tables have names of
the form
events_,
where xxx_summary_yyy_by_event_namexxx is
waits, stages, or
statements, and
yyy is account,
user, or host.
The connection summary tables provide an intermediate aggregation level:
xxx_summary_by_thread_by_event_name
xxx_summary_global_by_event_name
Each connection summary table has one or more grouping columns
to indicate how the table aggregates events. Event names refer
to names of event instruments in the
setup_instruments table.
For tables with _by_account in the
name, the USER,
HOST, and EVENT_NAME
columns group events per account and event name.
For tables with _by_host in the name,
the HOST and
EVENT_NAME columns group events per
host name and event name.
For tables with _by_user in the name,
the USER and
EVENT_NAME columns group events per
user name and event name.
Each connection summary table has these summary columns
containing aggregated values: COUNT_STAR,
SUM_TIMER_WAIT,
MIN_TIMER_WAIT,
AVG_TIMER_WAIT, and
MAX_TIMER_WAIT. These are similar to the
columns of the same names in the
events_waits_summary_by_instance
table. Connection summary tables for statements have
additional
SUM_ columns
that aggregate statement types.
xxx
The connection summary tables were added in MySQL 5.6.3.
TRUNCATE TABLE is permitted for
connection summary tables. It resets the summary columns to
zero rather than removing rows. In addition, connection
summary tables are implicitly truncated if a connection table
on which they depend is truncated.
Table 8.2, “Effect of Implicit Table Truncation”,
describes the relationship between connection table truncation
and implicitly truncated tables.
Table 8.2 Effect of Implicit Table Truncation
| Truncated Table | Implicitly Truncated Summary Tables |
|---|---|
accounts | Tables with names matching %_by_account%,
%_by_thread% |
hosts | Tables with names matching %_by_account%,
%_by_host%,
%_by_thread% |
users | Tables with names matching %_by_account%,
%_by_user%,
%_by_thread% |
These socket summary tables aggregate timer and byte count information for socket operations:
socket_summary_by_instance:
Aggregate timer and byte count statistics generated by the
wait/io/socket/* instruments for all
socket I/O operations, per socket instance. When a
connection terminates, the row in
socket_summary_by_instance
corresponding to it is deleted.
socket_summary_by_event_name:
Aggregate timer and byte count statistics generated by the
wait/io/socket/* instruments for all
socket I/O operations, per socket instrument.
The socket summary tables do not aggregate waits generated by
idle events while sockets are waiting for
the next request from the client. For idle
event aggregations, use the wait-event summary tables; see
Section 8.9.1, “Event Wait Summary Tables”.
Each socket summary table has one or more grouping columns to
indicate how the table aggregates events. Event names refer to
names of event instruments in the
setup_instruments table.
socket_summary_by_instance
has an OBJECT_INSTANCE_BEGIN column.
Each row summarizes events for a given object.
socket_summary_by_event_name
has an EVENT_NAME column. Each row
summarizes events for a given event name.
Each socket summary table has these summary columns containing aggregated values:
COUNT_STAR,
SUM_TIMER_WAIT,
MIN_TIMER_WAIT,
AVG_TIMER_WAIT,
MAX_TIMER_WAIT
These columns aggregate all operations.
COUNT_READ,
SUM_TIMER_READ,
MIN_TIMER_READ,
AVG_TIMER_READ,
MAX_TIMER_READ,
SUM_NUMBER_OF_BYTES_READ
These columns aggregate all receive operations
(RECV, RECVFROM, and
RECVMSG).
COUNT_WRITE,
SUM_TIMER_WRITE,
MIN_TIMER_WRITE,
AVG_TIMER_WRITE,
MAX_TIMER_WRITE,
SUM_NUMBER_OF_BYTES_WRITE
These columns aggregate all send operations
(SEND, SENDTO, and
SENDMSG).
COUNT_MISC,
SUM_TIMER_MISC,
MIN_TIMER_MISC,
AVG_TIMER_MISC,
MAX_TIMER_MISC
These columns aggregate all other socket operations, such
as CONNECT, LISTEN,
ACCEPT, CLOSE, and
SHUTDOWN. There are no byte counts for
these operations.
The socket_summary_by_instance
table also has an EVENT_NAME column that
indicates the class of the socket:
client_connection,
server_tcpip_socket,
server_unix_socket. This column can be
grouped on to isolate, for example, client activity from that
of the server listening sockets.
These tables were added in MySQL 5.6.3.
TRUNCATE TABLE is permitted for
socket summary tables. Except for
events_statements_summary_by_digest,
tt resets the summary columns to zero rather than removing
rows.
The following sections describe tables that do not fall into the table categories discussed in the preceding sections:
host_cache: Information from
the internal host cache
performance_timers: Which event
timers are available
threads: Information about
server threads
The host_cache table provides
access to the contents of the host cache, which contains
client host name and IP address information and is used to
avoid DNS lookups. (See DNS Lookup Optimization and the Host Cache.) The
host_cache table exposes the
contents of the host cache so that it can be examined using
SELECT statements. The
Performance Schema must be enabled or this table is empty.
FLUSH HOSTS
and TRUNCATE
TABLE host_cache have the same effect: They clear
the host cache. This also empties the
host_cache table (because it is
the visible representation of the cache) and unblocks any
blocked hosts (see Host 'host_name' is blocked.)
FLUSH HOSTS
requires the RELOAD privilege.
TRUNCATE TABLE requires the
DROP privilege for the
host_cache table.
The host_cache table has these
columns:
IP
The IP address of the client that connected to the server, expressed as a string.
HOST
The resolved DNS host name for that client IP, or
NULL if the name is unknown.
HOST_VALIDATED
Whether the IP-to-host name-to-IP DNS resolution was
performed successfully for the client IP. If
HOST_VALIDATED is
YES, the HOST column
is used as the host name corresponding to the IP so that
calls to DNS can be avoided. While
HOST_VALIDATED is
NO, DNS resolution is attempted again
for each connect, until it eventually completes with
either a valid result or a permanent error. This
information enables the server to avoid caching bad or
missing host names during temporary DNS failures, which
would affect clients forever.
SUM_CONNECT_ERRORS
The number of connection errors that are deemed
“blocking” (assessed against the
max_connect_errors system
variable). Only protocol handshake errors are counted, and
only for hosts that passed validation
(HOST_VALIDATED = YES).
COUNT_HOST_BLOCKED_ERRORS
The number of connections that were blocked because
SUM_CONNECT_ERRORS exceeded the value
of the max_connect_errors
system variable.
COUNT_NAMEINFO_TRANSIENT_ERRORS
The number of transient errors during IP-to-host name DNS resolution.
COUNT_NAMEINFO_PERMANENT_ERRORS
The number of permanent errors during IP-to-host name DNS resolution.
COUNT_FORMAT_ERRORS
The number of host name format errors. MySQL does not
perform matching of Host column values
in the mysql.user table against host
names for which one or more of the initial components of
the name are entirely numeric, such as
1.2.example.com. The client IP address
is used instead. For the rationale why this type of
matching does not occur, see
Specifying Account Names.
COUNT_ADDRINFO_TRANSIENT_ERRORS
The number of transient errors during host name-to-IP reverse DNS resolution.
COUNT_ADDRINFO_PERMANENT_ERRORS
The number of permanent errors during host name-to-IP reverse DNS resolution.
COUNT_FCRDNS_ERRORS
The number of forward-confirmed reverse DNS errors. These errors occur when IP-to-host name-to-IP DNS resolution produces an IP address that does not match the client originating IP address.
COUNT_HOST_ACL_ERRORS
The number of errors that occur because no user from the
client host can possibly log in. In such cases, the server
returns
ER_HOST_NOT_PRIVILEGED and
does not even ask for a user name or password.
COUNT_NO_AUTH_PLUGIN_ERRORS
The number of errors due to requests for an unavailable authentication plugin. A plugin can be unavailable if, for example, it was never loaded or a load attempt failed.
COUNT_AUTH_PLUGIN_ERRORS
The number of errors reported by authentication plugins.
An authentication plugin can report different error codes
to indicate the root cause of a failure. Depending on the
type of error, one of these columns is incremented:
COUNT_AUTHENTICATION_ERRORS,
COUNT_AUTH_PLUGIN_ERRORS,
COUNT_HANDSHAKE_ERRORS. New return
codes are an optional extension to the existing plugin
API. Unknown or unexpected plugin errors are counted in
the COUNT_AUTH_PLUGIN_ERRORS column.
COUNT_HANDSHAKE_ERRORS
The number of errors detected at the wire protocol level.
COUNT_PROXY_USER_ERRORS
The number of errors detected when a proxy user A is proxied to another user B who does not exist.
COUNT_PROXY_USER_ACL_ERRORS
The number of errors detected when a proxy user A is
proxied to another user B who does exist but for whom A
does not have the PROXY
privilege.
COUNT_AUTHENTICATION_ERRORS
The number of errors caused by failed authentication.
COUNT_SSL_ERRORS
The number of errors due to SSL problems.
COUNT_MAX_USER_CONNECTIONS_ERRORS
The number of errors caused by exceeding per-user connection quotas. See Setting Account Resource Limits.
COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS
The number of errors caused by exceeding per-user connections-per-hour quotas. See Setting Account Resource Limits.
COUNT_DEFAULT_DATABASE_ERRORS
The number of errors related to the default database. For example, the database did not exist or the user had no privileges for accessing it.
COUNT_INIT_CONNECT_ERRORS
The number of errors caused by execution failures of
statements in the
init_connect system
variable value.
COUNT_LOCAL_ERRORS
The number of errors local to the server implementation and not related to the network, authentication, or authorization. For example, out-of-memory conditions fall into this category.
COUNT_UNKNOWN_ERRORS
The number of other, unknown errors not accounted for by
other columns in this table. This column is reserved for
future use, in case new error conditions must be reported,
and if preserving the backward compatibility and table
structure of the host_cache
table is required.
FIRST_SEEN
The timestamp of the first connection attempt seen from
the client in the IP column.
LAST_SEEN
The timestamp of the last connection attempt seen from the
client in the IP column.
FIRST_ERROR_SEEN
The timestamp of the first error seen from the client in
the IP column.
LAST_ERROR_SEEN
The timestamp of the last error seen from the client in
the IP column.
The host_cache table was added in
MySQL 5.6.5.
The performance_timers table
shows which event timers are available:
mysql> SELECT * FROM performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE | 2389029850 | 1 | 72 |
| NANOSECOND | 1000000000 | 1 | 112 |
| MICROSECOND | 1000000 | 1 | 136 |
| MILLISECOND | 1036 | 1 | 168 |
| TICK | 105 | 1 | 2416 |
+-------------+-----------------+------------------+----------------+
The timers in setup_timers that
you can use are those that do not have NULL
in the other columns. If the values associated with a given
timer name are NULL, that timer is not
supported on your platform.
The performance_timers table has
these columns:
TIMER_NAME
The name by which to refer to the timer when configuring
the setup_timers table.
TIMER_FREQUENCY
The number of timer units per second. For a cycle timer,
the frequency is generally related to the CPU speed. For
example, on a system with a 2.4GHz processor, the
CYCLE may be close to 2400000000.
TIMER_RESOLUTION
Indicates the number of timer units by which timer values increase. If a timer has a resolution of 10, its value increases by 10 each time.
TIMER_OVERHEAD
The minimal number of cycles of overhead to obtain one timing with the given timer. The Performance Schema determines this value by invoking the timer 20 times during initialization and picking the smallest value. The total overhead really is twice this amount because the instrumentation invokes the timer at the start and end of each event. The timer code is called only for timed events, so this overhead does not apply for nontimed events.
The maximum number of rows in the table is autosized at
server startup. To set this maximum explicitly, set the
performance_schema_digests_size
system variable at server startup.
The threads table contains a row
for each server thread. Each row contains information about a
thread and indicates whether monitoring is enabled for it:
mysql> SELECT * FROM threads\G
*************************** 1. row ***************************
THREAD_ID: 1
NAME: thread/sql/main
TYPE: BACKGROUND
PROCESSLIST_ID: NULL
PROCESSLIST_USER: NULL
PROCESSLIST_HOST: NULL
PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: NULL
PROCESSLIST_TIME: 80284
PROCESSLIST_STATE: NULL
PROCESSLIST_INFO: NULL
PARENT_THREAD_ID: NULL
ROLE: NULL
INSTRUMENTED: YES
...
*************************** 4. row ***************************
THREAD_ID: 51
NAME: thread/sql/one_connection
TYPE: FOREGROUND
PROCESSLIST_ID: 34
PROCESSLIST_USER: isabella
PROCESSLIST_HOST: localhost
PROCESSLIST_DB: performance_schema
PROCESSLIST_COMMAND: Query
PROCESSLIST_TIME: 0
PROCESSLIST_STATE: Sending data
PROCESSLIST_INFO: SELECT * FROM threads
PARENT_THREAD_ID: 1
ROLE: NULL
INSTRUMENTED: YES
...
When the Performance Schema initializes, it populates the
threads table based on the
threads in existence then. Thereafter, a new row is added each
time the server creates a thread.
The INSTRUMENTED column value for new
threads is determined by the contents of the
setup_actors table. For
information about how to use the
setup_actors table to control
this column, see
Section 3.3.3.3, “Pre-Filtering by Thread”.
Removal of rows from the threads
table occurs when threads end. For a thread associated with a
client session, removal occurs when the session ends. If a
client has auto-reconnect enabled and the session reconnects
after a disconnect, the session becomes associated with a new
row in the threads table that has
a different PROCESSLIST_ID value. The
initial INSTRUMENTED value for the new
thread may be different from that of the original thread: The
setup_actors table may have
changed in the meantime, and if the
INSTRUMENTED value for the original thread
was changed after it was initialized, that change does not
carry over to the new thread.
The threads table columns with
names having a prefix of PROCESSLIST_
provide information similar to that available from the
INFORMATION_SCHEMA.PROCESSLIST
table or the SHOW PROCESSLIST
statement. Thus, all three sources provide thread-monitoring
information. Use of threads
differs from use of the other two sources in these ways:
Access to threads does not
require a mutex and has minimal impact on server
performance.
INFORMATION_SCHEMA.PROCESSLIST
and SHOW PROCESSLIST have
negative performance consequences because they require a
mutex.
threads provides additional
information for each thread, such as whether it is a
foreground or background thread, and the location within
the server associated with the thread.
threads provides information
about background threads, so it can be used to monitor
activity the other thread information sources cannot.
You can enable or disable thread monitoring (that is,
whether events executed by the thread are instrumented).
To control the initial INSTRUMENTED
value for new foreground threads, use the
setup_actors table. To
control monitoring of existing threads, set the
INSTRUMENTED column of
threads table rows. (For more
information about the conditions under which thread
monitoring occurs, see the description of the
INSTRUMENTED column.)
For these reasons, DBAs who perform server monitoring using
INFORMATION_SCHEMA.PROCESSLIST or
SHOW PROCESSLIST may wish to
monitor using the threads table
instead.
For
INFORMATION_SCHEMA.PROCESSLIST
and SHOW PROCESSLIST,
information about threads for other users is shown only if
the current user has the
PROCESS privilege. That is
not true of the threads table;
all rows are shown to any user who has the
SELECT privilege for the table. Users who
should not be able to see threads for other users should not
be given that privilege.
The threads table has these
columns:
THREAD_ID
A unique thread identifier.
NAME
The name associated with the thread instrumentation code
in the server. For example,
thread/sql/one_connection corresponds
to the thread function in the code responsible for
handling a user connection, and
thread/sql/main stands for the
main() function of the server.
TYPE
The thread type, either FOREGROUND or
BACKGROUND. User connection threads are
foreground threads. Threads associated with internal
server activity are background threads. Examples are
internal InnoDB threads, “binlog
dump” threads sending information to slaves, and
slave I/O and SQL threads.
PROCESSLIST_ID
For threads that are displayed in the
INFORMATION_SCHEMA.PROCESSLIST
table, this is the same value displayed in the
ID column of that table. It is also the
value displayed in the Id column of
SHOW PROCESSLIST output,
and the value that
CONNECTION_ID() would
return within that thread.
For background threads (threads not associated with a user
connection), PROCESSLIST_ID is
NULL, so the values are not unique.
(Before MySQL 5.6.9, the value is 0 for background
threads.)
PROCESSLIST_USER
The user associated with a foreground thread,
NULL for a background thread.
PROCESSLIST_HOST
The host name of the client associated with a foreground
thread, NULL for a background thread.
Unlike the HOST column of the
INFORMATION_SCHEMA
PROCESSLIST table or the
Host column of
SHOW PROCESSLIST output,
the PROCESSLIST_HOST column does not
include the port number for TCP/IP connections. To obtain
this information from the Performance Schema, enable the
socket instrumentation (which is not enabled by default)
and examine the
socket_instances table:
mysql>SELECT * FROM setup_instruments WHERE NAME LIKE 'wait/io/socket%';+----------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +----------------------------------------+---------+-------+ | wait/io/socket/sql/server_tcpip_socket | NO | NO | | wait/io/socket/sql/server_unix_socket | NO | NO | | wait/io/socket/sql/client_connection | NO | NO | +----------------------------------------+---------+-------+ 3 rows in set (0.01 sec) mysql>UPDATE setup_instruments SET ENABLED='YES' WHERE NAME LIKE 'wait/io/socket%';Query OK, 3 rows affected (0.00 sec) Rows matched: 3 Changed: 3 Warnings: 0 mysql>SELECT * FROM socket_instances\G*************************** 1. row *************************** EVENT_NAME: wait/io/socket/sql/client_connection OBJECT_INSTANCE_BEGIN: 140612577298432 THREAD_ID: 31 SOCKET_ID: 53 IP: ::ffff:127.0.0.1 PORT: 55642 STATE: ACTIVE ...
PROCESSLIST_DB
The default database for the thread, or
NULL if there is none.
PROCESSLIST_COMMAND
For foreground threads, the type of command the thread is
executing on behalf of the client, or
Sleep if the session is idle. For
descriptions of thread commands, see
Examining Thread Information. The value of this
column corresponds to the
COM_
commands of the client/server protocol and
xxxCom_
status variables. See
Server Status Variables
xxx
Background threads do not execute commands on behalf of
clients, so this column may be NULL.
PROCESSLIST_TIME
The time in seconds that the thread has been in its current state.
PROCESSLIST_STATE
An action, event, or state that indicates what the thread
is doing. For descriptions of
PROCESSLIST_STATE values, see
Examining Thread Information. If the value if
NULL, the thread may correspond to an
idle client session or the work it is doing is not
instrumented with stages.
Most states correspond to very quick operations. If a thread stays in a given state for many seconds, there might be a problem that bears investigation.
PROCESSLIST_INFO
The statement the thread is executing, or
NULL if it is not executing any
statement. The statement might be the one sent to the
server, or an innermost statement if the statement
executes other statements. For example, if a
CALL statement executes a stored
procedure that is executing a
SELECT statement, the
PROCESSLIST_INFO value shows the
SELECT statement.
PARENT_THREAD_ID
If this thread is a subthread (spawned by another thread),
this is the THREAD_ID value of the
spawning thread. Thread spawning occurs, for example, to
handle insertion of rows from INSERT
DELAYED statements.
ROLE
Unused.
INSTRUMENTED
Whether events executed by the thread are instrumented.
The value is YES or
NO.
For foreground threads, the initial
INSTRUMENTED value is determined by
whether the user account associated with the thread
matches any row in the
setup_actors table.
Matching is based on the values of the
PROCESSLIST_USER and
PROCESSLIST_HOST columns.
If the thread spawns a subthread, matching occurs
again for the threads
table row created for the subthread.
For background threads,
INSTRUMENTED is
YES by default.
setup_actors is not
consulted because there is no associated user for
background threads.
For any thread, its INSTRUMENTED
value can be changed during the lifetime of the
thread. This is the only
threads table column that
can be modified.
For monitoring of events executed by the thread to occur, these things must be true:
The thread_instrumentation consumer
in the setup_consumers
table must be YES.
The threads.INSTRUMENTED column
must be YES.
Monitoring occurs only for those thread events
produced from instruments that have the
ENABLED column set to
YES in the
setup_instruments table.