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 table. The
events_waits_current table
contains the most recent event for each thread.
History tables. These tables have the same structure as
events_waits_current but contain
more rows. The
events_waits_history table
contains the most recent 10 events per thread.
events_waits_history_long
contains the most recent 10,000 events.
To change the sizes of these tables, set the
performance_schema_events_waits_history_size
and
performance_schema_events_waits_history_long_size
system variables at server startup.
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 |
|---|---|
cond_instances | synchronization object instances |
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_instance | Wait events per instance |
events_waits_summary_by_thread_by_event_name | Wait events per thread 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 |
mutex_instances | Mutex synchronization object instances |
performance_timers | Which event timers are available |
rwlock_instances | Lock synchronization object instances |
setup_consumers | Consumers for which event information can be stored |
setup_instruments | Classes of instrumented objects for which events can be collected |
setup_timers | Current event timer |
threads | Information about server threads |
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_consumers: The types of
consumers for which event information can be stored
setup_instruments: The classes
of instrumented objects for which events can be collected
setup_timers: The current event
timer
The setup_consumers table lists
the types of consumers for which event information can be
stored:
mysql> SELECT * FROM setup_consumers;
+----------------------------------------------+---------+
| NAME | ENABLED |
+----------------------------------------------+---------+
| events_waits_current | YES |
| events_waits_history | YES |
| events_waits_history_long | YES |
| events_waits_summary_by_thread_by_event_name | YES |
| events_waits_summary_by_event_name | YES |
| events_waits_summary_by_instance | YES |
| file_summary_by_event_name | YES |
| file_summary_by_instance | YES |
+----------------------------------------------+---------+
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.
Disabling the events_waits_current consumer
disables everything else that depends on waits, such as the
events_waits_history and
events_waits_history_long tables,
and all summary tables.
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.
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_timers table shows the
currently selected event timer:
mysql> SELECT * FROM setup_timers;
+------+------------+
| NAME | TIMER_NAME |
+------+------------+
| wait | CYCLE |
+------+------------+
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 use the original timer for the begin time and the new
timer for the end time, which leads to unpredictable results.
If you make timer changes, you may want to 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
These tables list instrumented synchronization objects and
files. 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.
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.5.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.
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.
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.
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.
NESTING_EVENT_ID
Always NULL.
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.
FLAGS
Reserved for future use.
The events_waits_history table
contains the most recent 10 wait events per thread. To change
the table size, modify 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 10,000 wait events. To change
the table size, modify 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”.
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
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
The events_waits_summary_global_by_event_name
table was named
EVENTS_WAITS_SUMMARY_BY_EVENT_NAME before
MySQL 5.5.7.
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. 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.
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 and
EVENT_NAME columns. Each row summarizes
events for a given file instrument instance.
Each file I/O summary table has these summary columns containing aggregated values:
COUNT_READ
The number of read operations in the summarized events.
COUNT_WRITE
The number of write operations in the summarized events.
SUM_NUMBER_OF_BYTES_READ
The number of bytes read in the summarized events.
SUM_NUMBER_OF_BYTES_WRITE
The number of bytes written in the summarized events.
Example file I/O event summary information:
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
COUNT_READ: 3
COUNT_WRITE: 0
SUM_NUMBER_OF_BYTES_READ: 42211
SUM_NUMBER_OF_BYTES_WRITE: 0
...
*************************** 6. row ***************************
FILE_NAME: /var/mysql/data/binlog.000001
EVENT_NAME: wait/io/file/sql/binlog
COUNT_READ: 0
COUNT_WRITE: 0
SUM_NUMBER_OF_BYTES_READ: 0
SUM_NUMBER_OF_BYTES_WRITE: 0
...
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 tables that do not fall into the table categories discussed in the preceding sections:
performance_timers: Which event
timers are available
threads: Information about
server threads
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 | NULL | NULL | NULL |
| MICROSECOND | 1000000 | 1 | 585 |
| MILLISECOND | 1035 | 1 | 738 |
| TICK | 101 | 1 | 630 |
+-------------+-----------------+------------------+----------------+
If the values associated with a given timer name are
NULL, that timer is not supported on your
platform. The rows that do not contain NULL
indicate which timers you can use in
setup_timers.
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 threads table contains a row
for each server thread:
mysql> SELECT * FROM threads;
+-----------+----------------+----------------------------------------+
| THREAD_ID | PROCESSLIST_ID | NAME |
+-----------+----------------+----------------------------------------+
| 0 | 0 | thread/sql/main |
| 1 | 0 | thread/innodb/io_handler_thread |
| 16 | 0 | thread/sql/signal_handler |
| 23 | 7 | thread/sql/one_connection |
| 5 | 0 | thread/innodb/io_handler_thread |
| 12 | 0 | thread/innodb/srv_lock_timeout_thread |
| 22 | 6 | thread/sql/one_connection |
...
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
This is the unique identifier of an instrumented thread.
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 0, so
the values are not unique.
This column was named ID before MySQL
5.5.8.
NAME
NAME is the name associated with the
instrumentation of the 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.
The threads table was named
PROCESSLIST before MySQL 5.5.6.