As of MySQL Enterprise Monitor 3.0.0, Query Analyzer data is automatically collected and displayed by simply monitoring MySQL Server 5.6.14 or greater, and without any additional plugins required. This ability comes from the Performance Schema Statement Digests feature (Performance Schema Statement Digests) that was added in MySQL 5.6. If you are using an earlier version of MySQL Server (5.6.13 or below), then you can continue to use a Connector Plugin or MySQL Proxy to provide performance information to the Query Analyzer.

Collecting Query Analyzer data from Performance Schema, rather than at the wire protocol (which is how the other sources of Query Analyzer data work) provides data about what the statements do to generate their result sets that other sources cannot provide:

There is also information not available when operating in this mode that is provided to the Query Analyzer when using Connector Plugins and MySQL Proxy:

When enabled (which is the default), the MySQL Enterprise Monitor Agent polls the performance_schema.events_statements_summary_by_digest table (every minute, by default) and continually compute the deltas for each of the normalized statements that are exposed during the snapshot window. This is dependent on the Performance Schema setup having the "statements_digest" consumer enabled within performance_schema.setup_consumers, which is enabled by default in MySQL 5.6:

mysql> SELECT * FROM performance_schema.setup_consumers WHERE name = 'statements_digest';
+-------------------+---------+
| NAME              | ENABLED |
+-------------------+---------+
| statements_digest | YES     |
+-------------------+---------+

If this is not enabled, then enable it with:

UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name = 'statements_digest';

The performance_schema.events_statements_summary_by_digest table is a sized table in memory within the Performance Schema, and its size is auto-configured. To check the current size:

mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema_digests_size';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| performance_schema_digests_size | 5000  |
+---------------------------------+-------+

If your application executes more than this number of normalized statements, then it is possible that you may begin losing some statement instrumentation. You can monitor this situation with the Performance_schema_digest_lost system variable:

mysql> SHOW GLOBAL STATUS LIKE 'Performance_schema_digest_lost';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| Performance_schema_digest_lost | 0     |
+--------------------------------+-------+

If you detect that this counter variable is growing, consider increasing the performance_schema_digests_size system variable. It is also possible that your statement profile has changed over time, and that you are now executing different statements than were originally tracked (this is especially possible in very long running instances). In this case, you can simply TRUNCATE TABLE performance_schema.events_statements_summary_by_digest, and the Query Analyzer collection automatically starts again.

When the "Example Query" feature is enabled, Query Analyzer attempts to get an example of the longest running statement during the snapshot interval by doing a LEFT JOIN with a groupwise-max on the performance_schema.events_statements_summary_by_digest table to the performance_schema.events_statements_history_long table. Using this method does not guarantee that an example statement is always provided because, by default, the events_statements_history_long table is a ring buffer of the last 1000 statements executed. This too differs from the Connector Plugin and MySQL Proxy sources, which always provide an example per normalized statement, per snapshot, when enabled. We collect in this way with Performance Schema to minimize load on the monitored instance rather than polling the performance_schema.events_statements_history_long table at too high a frequently to try and gather statistics.

The "Example Query" feature requires that the events_statements_history_long table is enabled within performance_schema.setup_consumers (this is disabled by default within MySQL 5.6):

mysql> SELECT * FROM performance_schema.setup_consumers where name = 
'events_statements_history_long';
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| events_statements_history_long | NO      |
+--------------------------------+---------+

If this is not enabled, then enable it with:

UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name = 
'events_statements_history_long';

When "Example Query" and "Example Explain" are enabled, the MySQL Enterprise Monitor Agent attempts to run an EXPLAIN for each example statement that is discovered and ran for longer than the "Auto-Explain Threshold". Due to the way that Performance Schema exposes normalized statements, truncating any normalized statement that is longer than 1024 bytes due to memory concerns within the MySQL Server means it is possible that an EXPLAIN may fail because the truncated statements do not parse correctly when running the EXPLAIN.

Click on an individual query to see more detailed information about the individual query in a pop-up window. The available tabs within this window depend on whether you have configured the more detailed query information. By default, you see the Canonical Query view.

You can also view Example Query, which provides more detailed data about a specific query, including the data and parameters submitted. You can also enable Explain Query, which lets you remotely execute an EXPLAIN statement with the specified query and view the resulting information. Finally, you can view any graph data produced during the execution of the query by using the Graphs tab.

The MySQL Enterprise Monitor User Interface supports correlated graphs so that you can compare the graphed execution parameters, such as the server load, thread statistics, or RAM usage, against the queries that were being executed by the server or servers being monitored at that time.

You can use the correlated graphs in two different ways:

When using the correlated graphs, selecting an area within the graph sets the start and end time within the query filtering selection. You can combine with other filtering options, such as the Query Type, to zero in on the queries to examine.

To use the graphs in this manner, select a starting point and click, while holding down the button, drag a selection area to set the time-range for the query display. The time range that you select is displayed above the graph as you select the area.

To export the graph, see Section 18.1, “All Timeseries Graphs”.

You can filter the queries shown within the Query Analyzer table by using the form at the top of the table. The different fields of the form are used to specify the parameters for the filter process. Once you have specified a filter, all the queries and related statistics shown within the Query Analyzer table are displayed in relation to the filter settings. For example, by default, the filter settings show the queries for the last 30 minutes. All the statistics shown are relative to the last 30 minutes, including average, maximum and execution counts.

The filtering functionality is available in a simple format, supporting simple statement and timing based filtering, and an advanced option allowing you to filter by specific columns within the Query Analyzer table.

The basic filter options are:

To use the advanced filtering techniques, click show advanced. This provides additional filters:

All the filter settings that you specify are used collectively, that is, all the specified filter options are used to match against the list of queries.

When you have set your filter parameters, you can update the Query Analysis display by clicking the filter button. To reset the fields to the default settings click the reset button.

If you want to make the current filter options the default when viewing the Query Analyzer page, click the Save As Default button. The settings are saved for the current user only.

There are a number of settings related to the Query Analyzer data. To configure the Query Analyzer, go to the Configuration, Advisors page and select the Query Analysis Advisor category. Then choose Edit Advisor Configuration from the context menu of the Query Analysis Reporting Advisor.

Like with any Advisor, this may be set globally, or for a group or particular MySQL server.

Thee configuration options are:

You can also define a schedule for the advisor's data collection. For more information, see Section 19.4, “Advisor Schedules”

To get the text and details of the queries displayed on the Query Analyzer page, click one of the icons to the right of the Browse Queries label in the separator bar. The query information is exported as comma-separated data in a .csv file, with fields corresponding to the columns shown in the Monitor UI, and the time of the export encoded in the filename in UTC format. The icon representing a single page exports the query information for the currently displayed page only. The icon representing a stack of pages exports the query information for all available pages of query information.

Within the Query Analyzer pop-up, you can also export information about each data group as a .csv text file or a .png image file, using icons next to the labels on the left side. The output file is named according to the pattern Statement_Report_Summary_%server/group%_%creationtimestamp%.csv. The data exported by these icons includes: