Why I am So Excited About the MySQL Performance Schema

The improved Performance Schema in MySQL 5.6 provides a new way of investigating issues in the database. Many issues that previously required tools such as strace, dtrace, etc. can now be investigated directly from inside MySQL in a platform independent way using standard SQL statements.

The Performance Schema is enabled by default starting from the latest milestone release, 5.6.6. You have instruments which are the things you can measure, and consumers which are those that use the measurements. Not all instruments and consumers are enabled out of the box, however once the plugin is enabled, individual instruments and consumers can be switched on and off dynamically.

As an example take the case mentioned in What's the innodb main thread really doing? where the main InnoDB thread appears to be stuck in “doing background drop tables” even though no tables are being dropped. Now the underlying issue has been resolved in 5.6, but other issues could show up. So how would the Performance Schema help in cases like that?

First you need to ensure that the necessary instrumentations and consumers are enabled:

mysql> use performance_schema;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> UPDATE setup_consumers SET ENABLED = 'Yes' WHERE Name = 'events_waits_current';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1  Changed: 0  Warnings: 0

mysql> UPDATE setup_instruments SET ENABLED = 'Yes', TIMED = 'Yes' WHERE Name LIKE '%mutex%';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 145  Changed: 0  Warnings: 0

The mutex contention can now easily be investigated using the two tables events_waits_current and mutex_instances. The events_waits_current table will have a row for each combination of thread and event. Threads includes both background threads and foreground threads (those clients are using), so for example an interaction between the purge thread(s) in InnoDB and a query submitted by the application can be checked.

A very simple query to get the investigation started can look like:

SELECT w1.THREAD_ID AS Victim_Thread_ID, w1.EVENT_ID AS Victim_Event_ID,
       w1.EVENT_NAME AS Victim_Event_Name, w1.SOURCE AS Victim_Source,
       t1.NAME AS Victim_Thread_Name, t1.PROCESSLIST_ID AS Victim_Process_ID,
       t1.PROCESSLIST_INFO AS Victim_SQL,
       w2.THREAD_ID AS Culprit_Thread_ID, w2.EVENT_ID AS Culprit_Event_ID,
       w2.EVENT_NAME AS Culprit_Event_Name, w2.SOURCE AS Culprit_Source,
       t2.NAME AS Culprit_Thread_Name, t2.PROCESSLIST_ID AS Culprit_Process_ID,
       t2.PROCESSLIST_INFO AS Culprit_SQL
  FROM performance_schema.events_waits_current w1
       INNER JOIN performance_schema.mutex_instances mi ON mi.OBJECT_INSTANCE_BEGIN = w1.OBJECT_INSTANCE_BEGIN
       INNER JOIN performance_schema.events_waits_current w2 ON w2.THREAD_ID = mi.LOCKED_BY_THREAD_ID
       INNER JOIN performance_schema.threads t1 ON t1.THREAD_ID = w1.THREAD_ID
       INNER JOIN performance_schema.threads t2 ON t2.THREAD_ID = w2.THREAD_ID;

Once you have the basic information about the threads involved, you can look for more information. One example is to use the events_statements_current, events_statements_history, and events_statements_history_long tables to get more knowledge of any foreground threads involved.

If you attend MySQL Connect 2012, you will be able to learn more about the MySQL Performance Schema for example by attending the hands-on lab “Improving Performance with the MySQL Performance Schema (HOL10472)” where you will be able to try out the Performance Schema yourself.

If you cannot make it to MySQL Connect or cannot wait to try the Performance Schema yourself, you can download MySQL Server 5.6 from https://dev.mysql.com/downloads/mysql/5.6.html. I can also recommend downloading Mark Leith's ps_helper views and stored procedures.