Глава 31. Представление Query Analyzer

MySQL Query Analyzer позволяет вам контролировать SQL-операторы, выполненные на сервере MySQL, и показывает детали каждого запроса и время выполнения. Подобные запросы с различными литеральными значениями объединены для сообщения о целях.

Query Analyzer собирает информацию относительно SQL-операторов, которые клиентские приложения MySQL посылают в сервер MySQL, используя обзоры схемы Performance (MySQL Server 5.6.14 и выше). Данные могут быть собраны непосредственно от MySQL Server без дополнительной конфигурации, используя агент MySQL Enterprise Monitor.

Для получения дополнительной информации о пользовательском интерфейсе Query Analyzer см. раздел 31.3.

Как только данные собраны, вы рассматриваете и контролируете запросы, проверяете статистику выполнения, фильтруете и изучаете информацию. Сравнивая запросы с графами сервера, можно коррелировать выполнение запросов со статусом сервера. Для получения дополнительной информации о просмотре, фильтрации и сообщении о данных Query Analyzer см. раздел 31.3.

31.1. Обеспечение данных Query Analyzer

MySQL Query Analyzer получает данные из Performance Schema. Performance Schema предоставляет статистическую информацию о запросах, время выполнения, количество результатов и другие данные, чтобы показать и проанализировать на странице Query Analyzer.

Используя обзоры Performance Schema с MySQL Server 5.6.14 и выше, данные могут быть собраны непосредственно от MySQL Server без дополнительной конфигурации.

31.1.1. Применение MySQL Performance Schema

Данные Query Analyzer автоматически собраны и показаны, контролируя MySQL Server 5.6.14 или выше через функциональность Performance Schema Statement Digests (Performance Schema Statement Digests and Sampling), которую добавили в MySQL 5.6.

Невозможно получить данные об обзоре запросов из версий сервера MySQL до MySQL 5.6.14.

Сбор данных Query Analyzer из Performance Schema обеспечивает данные о том, как запросы производят свои наборы результатов:

Агент MySQL Enterprise Monitor проверяет таблицу performance_schema.events_statements_summary_by_digest (каждую минуту по умолчанию) и все время вычисляет дельты для каждого из нормализованных запросов, которые выставляются во время окна снимка. Это зависит от установки Performance Schema, позволяющей "statements_digest" в performance_schema.setup_consumers, что включено по умолчанию в MySQL 5.6:

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

Если это не позволено, включите:

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

Агент MySQL Enterprise Monitor Agent не делает TRUNCATE для таблицы performance_schema.events_statements_summary_by_digest каждый раз, когда это читается, поскольку это возможно, может быть востребовано другими процессами/инструментами, потребляющими эти данные. Из-за этого статистическая величина Max Latency о которой сообщают для нормализованного запроса в Query Analyzer, является на самом деле максимумом начиная с запуска MySQL Server или с последнего вызова TRUNCATE TABLE performance_schema.events_statements_summary_by_digest.

Максимальное пространство, доступное для вычисления обзора, составляет по умолчанию килобайт, запросы, превышающие эту длину, усечены.

С MySQL 5.7.8 и позже и с 5.6.26 и позже это значение может быть изменено при запуске сервера, установив переменную performance_schema_max_digest_length . В MySQL 5.6.24, 5.6.24, 5.7.6 и 5.7.7 вместо этого используется max_digest_length. Для MySQL 5.7 до 5.7.6 значение не может быть изменено. При этом это не может быть изменено для версий MySQL 5.6 до 5.6.24.

Таблица performance_schema.events_statements_summary_by_digest хранится в памяти в рамках Performance Schema, ее размер автоформируется. Чтобы проверить текущий размер:

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

Если ваше приложение выполняет больше, чем это количество нормализованных запросов, то возможно, что можно начать терять некоторую инструментовку запросов. Можно контролировать эту ситуацию переменной Performance_schema_digest_lost :

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

Если вы обнаруживаете, что эта переменная счетчика растет, рассмотрите увеличение performance_schema_digests_size . Также возможно, что ваш профиль запроса изменялся со временем, и вы теперь выполняете не те запросы, чем были первоначально прослежены (это особенно возможно в очень давно работающих экземплярах). В этом случае вы можете просто выполнить TRUNCATE TABLE performance_schema.events_statements_summary_by_digest, Query Analyzer автоматически начинает собирать данные снова.

Если включена функция Example Query, Query Analyzer пытается получить пример самого длинного запроса во время интервала снимка, делая LEFT JOIN с groupwise-max на таблице performance_schema.events_statements_summary_by_digest к таблице performance_schema.events_statements_history_long. Использование этого метода не гарантирует, что запрос в качестве примера всегда предоставляется потому, что по умолчанию таблица events_statements_history_long это кольцевой буфер последних 1000 выполненных запросов. Данные собраны таким образом из Performance Schema, чтобы минимизировать нагрузку на проверенном экземпляре вместо того, чтобы проверять таблицу performance_schema.events_statements_history_long слишком часто, чтобы попытаться собрать статистику.

Маленькое подмножество (приблизительно 2 МБ данных) снимка известных предшествующих значений сохраняется в памяти, остальное сбрасывается на диск. Буфер сохранен в $MYSQL_AGENT_HOME /spool/queryAnalysis.

Example Query требует, чтобы таблица events_statements_history_long была включена в performance_schema.setup_consumers (это отключено по умолчанию в MySQL 5.6):

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

Если это не позволено, включите:

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

Когда включены Example Query и Example Explain, MySQL Enterprise Monitor Agent пытается выполнить EXPLAIN для каждого запроса в качестве примера, который обнаружен и работал дольше Auto-Explain Threshold. Из-за способа, которым Performance Schema выставляет нормализованные запросы, усекая любой нормализованный запрос, который длинней 1024 байт из-за проблем памяти в MySQL Server, возможно, что EXPLAIN может потерпеть неудачу, потому что усеченные запросы не разбирают правильно, выполняя EXPLAIN.

31.2. Query Response Time index (QRTi)

QRTi это "Query Response Time index". Это "quality of service" для каждого запроса и использует формулу Apdex для вычисления: Apdex on Wikipedia.

Как QRTi определяется

Три условия измерения "optimum", "acceptable" и "unacceptable", которые определяются как:

Таблица 31.1. Определения значений QRTi

Тип Временные значения по умолчанию Назначенное значение ОписаниеЦвет

Optimum

100ms

1.00 (100%)

Оптимальный период времени

Зеленый

Acceptable

4 * Optimum -- 100ms to 400ms

0.50 (50%)

Приемлемый период времени

Желтый

Unacceptable

Exceeds Acceptable -- greater than 400ms

0.00 (0%)

Недопустимый период времени

Красный

Вычисление в качестве примера

Мы вычисляем среднее число, чтобы определить заключительное значение QRTi. Например, если есть 100 выполнений канонического запроса, где 60 закончены ниже 100 мс (оптимальный период времени), 30 между 100 мс и 400 мс (приемлемый период времени) и 10 заняли больше времени, чем 400 мс (недопустимое время), тогда QRTi:

((60 + (30/2) + (10*0)) / 100) = 0.75.

Чтение значения QRTi

У запросов, перечисленных на странице Query Analyzer, есть круговая диаграмма, на которую наносят цветную маркировку, представляющую разбивку, используемую в вычислении QRTi: зеленое представляет оптимальный процент, желтое приемлемый процент, красное недопустимый процент. Вы можете двигать мышь по самой круговой диаграмме, чтобы видеть общее количество выполнения запросов, которое находилось в пределах каждой категории, а также процент выполнения запросов в пределах той группы.

Таким образом, делая оптимизацию запросов, стоит начать с тех, у которых есть визуальная круговая диаграмма QRTi, которая является 100% красной, что означает, что у них также есть фактическая ценность QRTi 0. Это означает, что *все* выполнение того запроса заняло больше времени, чем приемлемый период времени (400 мс по умолчанию). Можно нажать на запрос, чтобы получить больше информации, такой как максимальное и среднее время выполнения запроса, среднее количество исследованных строк, среднее время ожидания блокировки, исследовать типовой запрос, посмотреть на пример плана EXPLAIN, видеть, было ли сделано полное сканирование таблицы, исследовать использование индекса и т.д.

Можно тогда проложить себе путь от запросов с ценностью QRTi 0 к тем, у которых есть ценность 1 (подразумеват, что все случаи запроса выполнились в течение оптимального периода времени). Как только вы переходите к сути дела, что у вас больше нет запросов с ценностью QRTi меньше 1, тогда можно войти в конфигурацию Query Analysis Reporting Advisor , изменить QRTi Threshold (целевое время) вниз, скажем, 50 мс и начать процесс снова и снова.

31.3. Пользовательский интерфейс Query Analyzer

Чтобы открыть Query Analyzer, выберите Queries из навигационного меню.

Рис. 31.1. Представление Query Analyzer

Example of the default query analyzer view.

Таблица 31.2. Управление Query Analyzer

ЭлементОписание

Filters

Query Analyzer: содержит следующие системные фильтры:

  • Administration Statements: фильтры на запросах типа GRANT, REVOKE, RESET, SET, SHOW, FLUSH, CACHE, KILL и SHUTDOWN.

  • All Statements: (умолчание) никакая фильтрация не определяется. Все запросы показаны.

  • DDL Statements: фильтры на запросах типа CREATE, DROP, ALTER, TRUNCATE и RENAME.

  • DML Statements: фильтры на запросах типа SELECT, INSERT, UPDATE, DELETE, REPLACE, CALL, LOAD, DO и HANDLER .

  • Prepared Statements: фильтры на запросах типа PREPARE, EXECUTE и DEALLOCATE.

  • Replication Statements: фильтры на запросах типа START, STOP, RESET, и CHANGE.

  • Statements with Errors: фильтры на продвинутых вариантах фильтра Total Errors > 0.

  • Statements with Full Table Scans: фильтры на продвинутых вариантах фильтра Table Scan и Total Table Scans > 0.

  • Statements with Max Exec Time Over 1 Second: фильтры на продвинутых вариантах фильтра Max Exec Time > 1.

  • Statements with Temporary Tables: фильтры на продвинутых вариантах фильтра Total Temporary Tables > 0.

  • Statements with Temporary Tables on Disk : фильтры на продвинутых вариантах фильтра Total Temporary Disk Tables > 0.

  • Statements with Warnings: фильтры на продвинутых вариантах фильтра Total Warnings > 0.

  • Table Maintenance Statements: фильтры на запросах типа OPTIMIZE, ANALYZE, CHECK, REPAIR, и CHECKSUM.

  • Transactional and Locking Statements: фильтры на запросах типа BEGIN, COMMIT, ROLLBACK, SAVEPOINT, RELEASE, LOCK и UNLOCK.

  • Настроенные версии системных фильтров создаются, используя название фильтра с суффиксом -clone.

Configure View

Открывает представление конфигурации.

Configure View позволяет вам настроить данные, показанные согласно представлению Query Analyzer, см. раздел 31.5.

Statements

Панель statements показывает данные о запросе. Показанные данные формируются в разделе Data View в Configuration View.

См. Data View.

По умолчанию представление запросов показывает следующее:

  • Круговая диаграмма QRTi: визуальное представление индекса времени отклика запроса. Двигайте курсор по круговой диаграмме, чтобы видеть резюме процентов QRTi Optimal, Acceptable и Unacceptable.

  • Query: показывает нормализованный запрос. Двигайте курсор по запросу, чтобы видеть полную версию. Или щелкните по запросу, чтобы открыть страницу Details.

  • Database: название базы данных, на которой был выполнен запрос.

  • First Seen: время и дата, когда этот запрос был увиден в первый раз в базе данных.

  • Latency: граф, показывающий время ожидания запроса. Двигайте курсор по графу, чтобы показать всплывающую подсказку, содержащую резюме времени ожидания.

  • Total: общая сумма времени, потраченая на этот запрос.

  • Execution Counts: сколько раз этот запрос был выполнен.

  • Rows: количество строк затронуто этим запросом.

Все элементы представления запроса конфигурируемы, за исключением самого запроса, который всегда показывается. Чтобы показать полный запрос, наведите курсор на строку запроса. Полный запрос показан во всплывающем окне. Чтобы посмотреть детали запроса, щелкните по нему.

Для получения дополнительной информации о странице Details см. раздел 31.4.

31.4. Подробная информация о запросе

Нажмите на отдельный запрос, чтобы видеть более подробную информацию об отдельном запросе в представлении Details.

Для получения дополнительной информации о Normalization and Statement Digests см. Performance Schema Statement Digests and Sampling.

Если вы изменяете контекст, выбирая другой сервер MySQL из меню All Targets, а он не содержит обзор первоначально выбранного запроса, ошибка показана.

Страница деталей содержит следующие элементы:

Нормализованный SQL-оператор и статистика

Normalized SQL Statement показывает нормализованную версию SQL-оператора в то время, как Statistics показывает полезную информацию о выполнении запроса.

Рис. 31.2. Normalized Queries and Statistics

Example of the normalized queries and statistics frames.

Графы

Граф запроса показывает среднее время выполнения, количество выполнений и количество затронутых строк.

Рис. 31.3. Графы деталей запроса

Example of the query details graphs.

Example Statements, Details и EXPLAIN

Диаграмма распределения Example Statements графически представляет запрос по времени выполнения и дате и времени. Каждый пункт на диаграмме представляет определенное время выполнения запроса.

Рис. 31.4. Диаграмма распределения Example Statements

Example of the example statements distribution chart.

Запросы со связанным планом EXPLAIN представляются кругом в Distribution Chart. У площадей нет плана EXPLAIN. Красный круг или квадрат это SQL-оператор с самым долгим временем выполнения в течение установленного периода. Нажатие на круг или квадрат показывает свой текст запроса в оригинальной форме, подробностях выполнения и его плане EXPLAIN, если EXPLAIN позволен. Отбор одного из пунктов загружает данные для того пункта в структурах деталей Example:

Рис. 31.5. Example Statement и Details

Example of the example statement and details frames.

Рис. 31.6. Пример EXPLAIN

Example of the EXPLAIN plan.

31.5. Представление Query Analyzer Configuration

Configuration View позволяет вам настроить данные, показанные согласно представлению Query Analyzer.

Рис. 31.7. Configuration View

Example of the query analyzer configuration view.

Селектор Graph View

Позволяет вам выбрать графы, показанные согласно представлению Query Analyzer и диапазону времени выбранных графов.

Чтобы выбрать диапазон времени для графов, выберите значение из секции Zoom. Возможные значения колеблются от одного часа до двух дней.

Чтобы выбрать один или несколько графов, чтобы показать согласно представлению Query Analyzer, щелкните в рамке выбора Graph и выберите необходимые графы из доступных параметров.

Рис. 31.8. Graph View

Example of the query analyzer graphs configuration view.

Filter View

Рис. 31.9. Filter View

Example of the query analyzer filter configuration view.

Следующее это возможные варианты фильтра:

Представление Sort

Представление Sort позволяет вам определить, как данные упорядочены в представлении Statements.

Рис. 31.10. Представление View

Example of the query analyzer sort configuration view.

Data View

Data View формирует элементы, показанные в записях представления Statement.

Рис. 31.11. Data View

Example of the query analyzer data configuration view.

Возможные свойства следующие:

Настройка фильтров

Фильтры могут быть созданы (или существующие настроены) в Query Analyzer Configuration View.

Чтобы создать пользовательский фильтр, можно создать фильтр и сохранить его нажатием Save as... или создать новый фильтр при нажатии New, определить критерии фильтра и нажать Save as....

Можно также создать фильтр при помощи существующего фильтра как шаблон. Выберите фильтр и внесите ваши изменения. Если вы создаете названный фильтр на основе существующего фильтра, -clone добавляется к имени, когда вы редактируете новый фильтр. Имя может быть отредактировано как требуется.

Системные фильтры перечисляются с замком на левой стороне их имени. Они не могут быть отредактированы, но могут использоваться в качестве шаблонов для новых фильтров.

Чтобы установить фильтр как умолчание, выберите его в выпадающем списке и выберите Set as Default из смежного выпадающего меню. Звезда показана рядом с фильтром по умолчанию.

Если вы модернизировали от предыдущей версии и использовали умолчание, ваш фильтр переносится и переименовывается в User Default.