Статистика работы сервера представления в графической инструментальной панели. Чтобы показать инструментальную панель, откройте вкладку запроса и затем нажмите Dashboard из области Performance боковой панели Navigator с выбранной вкладки Management.
Эта особенность требует MySQL Server 5.6 или выше.
Рис. 7.1. Performance: инструментальная панель

Это подчеркивает статистику для сетевого трафика, посланного и полученного сервером MySQL по связям клиента. Точки данных включают Incoming Network Traffic, Outgoing Network Traffic и Client Connections.
Это подчеркивает основную статистику деятельности и работы сервера MySQL. Точки данных включают Table Open Cache, SQL Statements Executed, количество (в секунду) SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER и DROP.
Это предоставляет обзор пула буферов InnoDB и активности диска, которая произведена механизмом хранения InnoDB. Точки данных разделены на три группы:
Наведите курсор мыши на граф, чтобы видеть дополнительную информацию, такую как полное количество.
Usage
Read Requests: количество запросов логического чтения (в секунду) InnoDB к пулу буферов.
Writes
Data Written: количество записей в файл журнала отката InnoDB.
Reads
Doublewrite Buffer Writes: количество операций doublewrite, которые были выполнены.
Основанные на исполнительной схеме отчеты обеспечивают понимание операций по серверу MySQL через полезные отчеты высокого уровня. MySQL Workbench использует представления SYS на Performance Schema, чтобы произвести более 20 отчетов и помочь проанализировать исполнение ваших баз данных MySQL. Отчеты помогают проанализировать горячие точки IO, обнаружить дорогостоящие SQL-операторы и изучить статистика и метрики InnoDB. Для получения дополнительной информации о схеме SYS см. MySQL sys Schema.
Эта особенность требует MySQL Server 5.6 или выше.
GUI для формирования и точной настройки инструментовки Performance Schema. Первоначально это загружает вкладку Easy Setup, которая является достаточной для большинства пользователей. Чтобы позволить все доступные инструменты Performance Schema, наведите мышь на Fully Enabled и щелкните по кругу на панели.
Схема SYS встроена в MySQL Server 5.7 и выше, MySQL Workbench использует эту версию. Однако для MySQL Server 5.6 Workbench устанавливает свою собственную комплектную версию схемы SYS.
Эта особенность требует MySQL Server 5.6 или выше.
Размер сохраненного запроса определяется сервером MySQL.
Рис. 7.2. Настройка Performance Schema
Нажим предоставляет методы, чтобы точно настроить инструментовку Performance Schema.
Рис. 7.3. Настройка Performance Schema: обзор
Данные отчета об исполнении могут быть просмотрены и экспортированы с использованием следующих средств управления:
: Экспортируйте все записи и связанные данные (и заголовки столбцов) из текущего отчета об исполнении, который включает все и запросы и значения. Открывает диалог файла для экспорта.
Рис. 7.4. Отчет об исполнении: максимум I/0 в байтах
Доступные отчеты об исполнении включают (это не исчерпывающий список):
Top File I/O Activity Report : Покажите файлы, выполняющие большую часть IO (в байтах).
INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
по схемам.INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
по схемам и именам таблиц.Вкладка результатов Query Stats редактора SQL использует данные Performance Schema, чтобы собрать ключевые статистические данные, собранные для выполненного запроса, такие как выбор времени, временные таблицы, индексы, соединения и т.д.
MySQL server 5.6 или выше.
performance_schema
с инструментовкой запросов.Рис. 7.5. SQL Editor: статистика запроса

Рис. 7.6. SQL Editor: статистика запроса с исполнительными графами схемы
Visual Explain производит и показывает визуальное представление MySQL
EXPLAIN при помощи расширенной информации,
доступной в расширенном формате JSON.
Расширенный формат EXPLAIN
доступен, начиная с сервера MySQL 5.6.5.
MySQL Workbench обеспечивает все форматы
EXPLAIN для выполненных запросов, включая
расширенный JSON, традиционный формат и визуальный план запросов.
Диаграмма Visual Explain ниже показывает визуальное представление следующего запроса:
SELECT CONCAT(customer.last_name, ', ', customer.first_name)
AS customer, address.phone, film.title FROM rental
INNER JOIN customer ON rental.customer_id = customer.customer_id
INNER JOIN address ON customer.address_id = address.address_id
INNER JOIN inventory ON rental.inventory_id = inventory.inventory_id
INNER JOIN film ON inventory.film_id = film.film_id
WHERE rental.return_date IS NULL AND
rental_date+INTERVAL film.rental_duration
DAY < CURRENT_DATE() LIMIT 5;
Рис. 7.7. Пример Visual Explain
Порядок выполнения: снизу вверх и слева направо.
Стандартные рамки: таблицы.
Стандартный текст ниже рамки: имя (или псевдоним) таблицы.
Следующая таблица показывает связанные цвета и описания, используемые в диаграмме Visual Explain. Для получения дополнительной информации о сметах см. The Optimizer Cost Model.
Таблица 7.1. Информация о диаграмме Visual Explain
| Имя системы | Цвет | Текст на визуальной диаграмме | Соответствующая информация подсказки |
|---|---|---|---|
| SYSTEM | Голубой | Single row: system constant | Очень низкая стоимость |
| CONST | Голубой | Single row: constant | Очень низкая стоимость |
| EQ_REF | Зеленый | Unique Key Lookup | Низкая стоимость: оптимизатор в состоянии найти индекс, который это может использовать, чтобы получить необходимые записи. Это быстро, потому что поиск по индексу непосредственно приводит к странице со всеми данными о строке |
| REF | Зеленый | Non-Unique Key Lookup | Низкая стоимость, если количество соответствий строкам маленькое, растет как увеличение количества строк |
| FULLTEXT | Желтый | Fulltext Index Search | Специализированный полнотекстовый поиск. Низкая стоимость для этого специализированного поиска |
| REF_OR_NULL | Зеленый | Key Lookup + Fetch NULL Values | Низкая стоимость, если количество соответствий строк маленькое, растет как увеличение количества строк |
| INDEX_MERGE | Зеленый | Index Merge | Средняя стоимость: ищет лучший выбор индекса в запросе, чтобы улучшить работу |
| UNIQUE_SUBQUERY | Оранжевый | Unique Key Lookup into table of subquery | Низкая стоимость: используется для эффективной обработки подзапроса |
| INDEX_SUBQUERY | Оранжевый | Non-Unique Key Lookup into table of subquery | Низкая стоимость: используется для эффективной обработки подзапроса |
| RANGE | Оранжевый | Index Range Scan | Средняя стоимость: частичный просмотр индекса |
| INDEX | Красный | Full Index Scan | Высокая стоимость: специально для больших индексов |
| ALL | Красный | Full Table Scan | Очень высокая стоимость: очень дорогостоящий для больших таблиц, но уменьшается для маленьких. Никакие применимые индексы не были найдены для таблицы, которая вынуждает оптимизатор искать каждую строку. Это может также означать, что диапазон поиска так широк, что индекс был бы бесполезен. |
| UNKNOWN | Черный | unknown | Это значение по умолчанию в случае, если соответствие не может быть определено |
Чтобы просмотреть план visual explain, выполните ваш запрос из
редактора SQL и затем выберите подвкладку Execution
Plan на вкладке результатов запроса. По умолчанию план выполнения
"Visual Explain", но также имеет представление "Tabular Explain", которое
подобно тому, что вы видели бы, выполняя
EXPLAIN в клиенте MySQL.
Эта обучающая программа описывает, как использовать отчеты Explain, чтобы определить местонахождение и зафиксировать проблематичные (медленные) запросы. Это использует DBT-3 database и начинается со следующего примера простого запроса.
SELECT * FROM orders
WHERE YEAR(o_orderdate) = 1992 AND
MONTH(o_orderdate) = 4 AND o_clerk LIKE '%0223';
Пример вопроса был сначала выполнен в визуальном редакторе SQL.
Затем отчет Explain был произведен при нажатии в меню на
и
.
Первоначальное сообщение показывает Visual Explain с информацией, которая
появляется, когда вы перемещаете свое указывающее устройство над таблицей
orders в полном сканировании таблицы.
Рис. 7.8. DBT-3 Explain: Visual Explain с Full Table Scan
Произвольно, можно переключиться на Tabular Explain. Используйте выпадающий список, чтобы переключиться между визуальными и табличными представлениями.
Рис. 7.9. DBT-3 Explain: Tabular Explain с Full Table Scan
Вопросы об этом запросе:
Почему этот запрос производил полное сканирование таблицы?
o_orderdate
не применен как возможный ключ?Смотря более внимательно, также заметьте, что индексированный столбец
используется в выражении "WHERE YEAR(o_orderdate) =
1992 AND MONTH(o_orderdate) = 4", таким образом, индекс не
используется. Чтобы использовать существующий индекс, можно приспособить
запрос следующим образом.
SELECT * FROM orders
WHERE o_orderdate BETWEEN '1992-04-01' AND '1992-04-30' AND
o_clerk LIKE '%0223';
Обновленные результаты запроса в качестве примера в Visual Explain,
в котором Index Range Scan заменяет
Full Table Scan, произведенный
последним примером запроса.
Рис. 7.10. DBT-3 Explain: Visual Explain с Index Range Scan
Рис. 7.11. DBT-3 Explain: Tabular Explain с Index Range Scan
Заметьте различия. Type, измененный с ALL
на range, возможные ключи (и используемый ключ)
изменены с NULL на
i_o_orderdate, количество просмотренных строк
изменено с 1.5 миллионов до приблизительно 33 тысяч. Это, конечно, та еще
разница. Однако, просмотр 33 тысяч, возвращая всего 18, это слишком.
Таким образом, акцент может быть перенесен на столбец
o_clerk. Следующий пример запроса
добавляет следующий индекс, который должен улучшить работу.
CREATE INDEX i_o_clerk ON orders(o_clerk);
Рис. 7.12. DBT-3 Explain: Tabular Explain с Index Range Scan и After Index
Новый индекс не рассматривают как возможный ключ, потому что запрос ищет
суффикс o_clerk и индексы не работают с
суффиксами (хотя они действительно работают с префиксами). Вместо этого этот
простой пример мог использовать clerk ID.
Наладка запроса следующим образом показывает лучшие результаты.
SELECT * FROM orders WHERE o_orderdate BETWEEN '1992-04-01' AND '1992-04-30'
AND o_clerk LIKE 'Clerk#000000223';
Рис. 7.13. DBT-3 Explain: Visual Explain с Index Range Scan и Full ID
Рис. 7.14. DBT-3 Explain: Tabular Explain с Index Range Scan и Full ID
Новый индекс o_clerk использован, запрос
просмотрел 1546 строк вместо 32642, выполнение запроса улучшено с 0.281 до
0.234 секунд. Однако, EXPLAIN показывает,
что этот запрос просматривает 1546 строк, чтобы возвратить 18.
После рассмотрения запроса снова, предположим, что многостолбцовый индекс
может удовлетворить условиям WHERE,
который основан на обоих столбцах o_orderdate и
o_clerk.
CREATE INDEX io_clerk_date ON orders(o_clerk, o_orderdate)
o_clerk появляется как первый столбец в
индексе, потому что o_orderdate
использует диапазон.
Теперь выполнение приспособленного запроса приводит к еще лучшим результатам. Приблизительно 18 строк просмотрены и возвращены, время выполнения примера запроса составляет 0.234 секунды.
Рис. 7.15. DBT-3 Explain: Visual Explain с Multiple-Column Index Range Scan
Рис. 7.16. DBT-3 Explain: Tabular Explain с Multiple-Column Index Range Scan
Таблица, которая следует дальше, суммирует результаты модификаций, сделанных во время этой обучающей программы.
Таблица 7.2. Сравнение запросов в DBT-3 Explain
| Type | Возможные ключи | Ключ | Просмотренные строки | Продолжительность (секунды) | Дополнительная информация | Строк возвращено |
|---|---|---|---|---|---|---|
| Все | NULL | NULL | 1.50M | 1.201 | Используя where | 18 |
| Диапазон | i_o_orderdate | i_o_orderdate | 32642 | 0.281 | Используя условие индекса и where | 18 |
| Диапазон | i_o_orderdate, i_o_clerk | i_o_clerk | 1546 | 0.234 | Используя условие индекса и where | 18 |
| Диапазон | i_o_orderdate, i_o_clerk, i_o_clerk_date | i_o_clerk_date | 18 | 0.234 | Используя условие индекса | 18 |