WebMoney: WMZ Z294115950220 WMR R409981405661 WME E134003968233 |
Visa 4274 3200 2453 6495 |
Статистика работы сервера представления в графической инструментальной
панели. Чтобы показать инструментальную панель, откройте вкладку запроса
и затем нажмите 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 Нажим Рис. 7.3. Настройка Performance Schema: обзор Данные отчета об исполнении могут быть просмотрены и экспортированы с
использованием следующих средств управления: : Экспортируйте все записи и
связанные данные (и заголовки столбцов) из текущего отчета об исполнении,
который включает все и запросы и значения.
Открывает диалог файла для экспорта. Рис. 7.4. Отчет об исполнении: максимум I/0 в байтах Доступные отчеты об исполнении включают (это не исчерпывающий список): Top File I/O Activity Report
: Покажите файлы, выполняющие большую часть IO (в байтах). Вкладка результатов Query Stats редактора
SQL использует данные Performance Schema, чтобы собрать ключевые
статистические данные, собранные для выполненного запроса, такие как выбор
времени, временные таблицы, индексы, соединения и т.д. MySQL server 5.6 или выше. Рис. 7.5. SQL Editor: статистика запроса Рис. 7.6. SQL Editor: статистика запроса с
исполнительными графами схемы Visual Explain производит и показывает визуальное представление MySQL
Расширенный формат MySQL Workbench обеспечивает все форматы
Диаграмма Visual Explain ниже показывает визуальное
представление следующего запроса:
Рис. 7.7. Пример Visual Explain Порядок выполнения: снизу вверх и слева направо. Стандартные рамки: таблицы. Стандартный текст ниже рамки: имя (или псевдоним) таблицы. Следующая таблица показывает связанные цвета и описания, используемые в
диаграмме Visual Explain. Для получения дополнительной информации о сметах
см. The Optimizer Cost Model. Таблица 7.1. Информация о диаграмме Visual Explain Чтобы просмотреть план visual explain, выполните ваш запрос из
редактора SQL и затем выберите подвкладку Execution
Plan на вкладке результатов запроса. По умолчанию план выполнения
"Visual Explain", но также имеет представление "Tabular Explain", которое
подобно тому, что вы видели бы, выполняя
Эта обучающая программа описывает, как использовать отчеты Explain, чтобы
определить местонахождение и зафиксировать проблематичные (медленные)
запросы. Это использует
DBT-3 database и начинается со следующего примера простого запроса.
Пример вопроса был сначала выполнен в визуальном редакторе SQL.
Затем отчет Explain был произведен при нажатии в меню на
Рис. 7.8. DBT-3 Explain: Visual Explain с Full Table Scan Произвольно, можно переключиться на Tabular Explain.
Используйте выпадающий список, чтобы переключиться между
визуальными и табличными представлениями. Рис. 7.9. DBT-3 Explain: Tabular Explain с Full Table Scan Вопросы об этом запросе: Почему этот запрос производил полное сканирование таблицы? Смотря более внимательно, также заметьте, что индексированный столбец
используется в выражении Обновленные результаты запроса в качестве примера в Visual Explain,
в котором Рис. 7.10. DBT-3 Explain: Visual Explain с Index Range Scan Рис. 7.11. DBT-3 Explain: Tabular Explain с Index Range Scan Заметьте различия. Type, измененный с Рис. 7.12. DBT-3 Explain: Tabular Explain с Index Range
Scan и After Index Новый индекс не рассматривают как возможный ключ, потому что запрос ищет
суффикс Рис. 7.13. DBT-3 Explain: Visual Explain с
Index Range Scan и Full ID Рис. 7.14. DBT-3 Explain: Tabular Explain с Index
Range Scan и Full ID Новый индекс Теперь выполнение приспособленного запроса приводит к еще лучшим
результатам. Приблизительно 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
Глава 7. Исполнительные инструменты
7.1. Исполнительная инструментальная панель
Сетевой статус
Статус MySQL
Статус InnoDB
7.2. Отчеты о схеме Performance
Установка и конфигурация
Средства управления отчетом об исполнении
Описание отчета об исполнении
INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
по схемам.INFORMATION_SCHEMA.INNODB_BUFFER_PAGE
по схемам и именам таблиц.7.3. Статистика запроса
Требования
performance_schema
с инструментовкой запросов.
7.4. План Visual Explain
EXPLAIN
при помощи расширенной информации,
доступной в расширенном формате JSON.
EXPLAIN
доступен, начиная с сервера MySQL 5.6.5.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;
Графические соглашения
Текстовые соглашения
Имя системы Цвет
Текст на визуальной диаграмме
Соответствующая информация подсказки 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
EXPLAIN
в клиенте MySQL.
7.5. Обучающая программа: использование Explain, чтобы
улучшить производительность запросов
SELECT * FROM orders
WHERE YEAR(o_orderdate) = 1992 AND
MONTH(o_orderdate) = 4 AND o_clerk LIKE '%0223';
orders
в полном сканировании таблицы.
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';
Index Range Scan
заменяет
Full Table Scan
, произведенный
последним примером запроса.
ALL
на range
, возможные ключи (и используемый ключ)
изменены с NULL
на
i_o_orderdate
, количество просмотренных строк
изменено с 1.5 миллионов до приблизительно 33 тысяч. Это, конечно, та еще
разница. Однако, просмотр 33 тысяч, возвращая всего 18, это слишком.
Таким образом, акцент может быть перенесен на столбец
o_clerk
. Следующий пример запроса
добавляет следующий индекс, который должен улучшить работу.
CREATE INDEX i_o_clerk ON orders(o_clerk);
o_clerk
и индексы не работают с
суффиксами (хотя они действительно работают с префиксами). Вместо этого этот
простой пример мог использовать clerk ID.
Наладка запроса следующим образом показывает лучшие результаты.
SELECT * FROM orders WHERE o_orderdate BETWEEN '1992-04-01' AND '1992-04-30'
AND o_clerk LIKE 'Clerk#000000223';
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
использует диапазон.
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
Найди своих коллег! |
Вы можете направить письмо администратору этой странички, Алексею Паутову.