[Эта статья была написана Робертом Барабасом]
Я подумал, что стоит потратить время на повторение настроек по умолчанию, связанных с новой схемой производительности, которые MySQL 5.7.7 вносит в таблицу по разным причинам.
С одной стороны, большинство из вас могли заметить, что профилирование было помечено как устаревшее в MySQL 5.6.7 . Поэтому ожидается, что вы инвестируете больше в изучение схемы производительности (и схемы sys Марка!).
Во-вторых, существует множество виртуальных сред и устройств, работающих под управлением Community Edition MySQL, где Performance Schema может быть полезным инструментом для анализа производительности. Таким образом, ожидайте увидеть больше статей об использовании PERFORMANCE_SCHEMA и SYS_SCHEMA от нас!
В-третьих, у нас появляется все больше и больше читателей младшего возраста, которые могут извлечь пользу из легких чтений, подобных этому.
Новые значения по умолчанию, которые я хотел выделить, упоминаются в примечаниях к выпуску MySQL 5.7.7 :
— Схема MySQL sys теперь устанавливается по умолчанию во время установки каталога данных.
— Потребители events_statements_history и events_transactions_history теперь включены по умолчанию.
Обратите внимание, что если вы обновляете более раннюю версию MySQL до 5.7.7, чтобы получить эти плюсы, вам нужно будет запустить mysql_upgrade и перезапустить базу данных, чтобы вышеуказанные изменения вступили в силу.
Так что это значит?
Если у вас не было возможности покопаться в PERFORMANCE_SCHEMA, ознакомьтесь с кратким руководством по началу работы здесь . PERFORMANCE_SCHEMA — это удобный инструмент (реализованный как объединение механизма хранения и схемы в MySQL) для мониторинга выполнения сервера MySQL на низком уровне с акцентом на метриках производительности. Он отслеживает события, которые были «инструментированы», такие как вызовы функций, время ожидания ОС, вызовы синхронизации и т. Д. С помощью номенклатуры производительности «инструменты» по сути являются «зондами». События, которые генерируют инструменты, могут быть обработаны потребителями. Обратите внимание, что не все инструменты или потребители включены по умолчанию.
Кто-то скажет, что структура PERFORMANCE_SCHEMA может быть сложной и не очень удобной для администраторов баз данных. Это то, что привело к рождению SYS_SCHEMA. Для тех, кто не знаком с SYS_SCHEMA Марка Лейта и предпочитает TL; DR — он предоставляет удобные для человека представления, функции и процедуры, которые могут помочь вам проанализировать использование базы данных с помощью PERFORMANCE_SCHEMA . Если у вас еще не было возможности проверить это, возможно, вы захотите прочитать статью Мигеля об использовании схемы sys или статью Александра Рубина об использовании ее в мультитенантных средах и дать ей шанс !
Я приветствую тот факт, что приемники events_statements_history и events_transactions_history по умолчанию включены в MySQL 5.7.7, поскольку это означает, что мы получаем некоторые полезные сведения о производительности, доступные нам из коробки в vanilla MySQL. Обратите внимание, что это таблицы для каждого потока, и по умолчанию длина истории (длина количества присутствующих записей; подробнее об этих переменных здесь ) автоматически измеряется, поэтому вам может потребоваться увеличить их.
Какие детали ты имеешь в виду?
Рассмотрим следующий пример:
mysql> select * from performance_schema.events_statements_history where event_id=353G
*************************** 1. row ***************************
THREAD_ID: 20
EVENT_ID: 353
END_EVENT_ID: 456
EVENT_NAME: statement/sql/select
SOURCE: mysqld.cc:963
TIMER_START: 1818042501405000
TIMER_END: 1818043715449000
TIMER_WAIT: 1214044000
LOCK_TIME: 67000000
SQL_TEXT: select * from imdb.title limit 100
DIGEST: ec93c38ab021107c2160259ddee31faa
DIGEST_TEXT: SELECT * FROM `imdb` . `title` LIMIT ?
CURRENT_SCHEMA: performance_schema
OBJECT_TYPE: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
OBJECT_INSTANCE_BEGIN: NULL
MYSQL_ERRNO: 0
RETURNED_SQLSTATE: NULL
MESSAGE_TEXT: NULL
ERRORS: 0
WARNINGS: 0
ROWS_AFFECTED: 0
ROWS_SENT: 100
ROWS_EXAMINED: 100
CREATED_TMP_DISK_TABLES: 0
CREATED_TMP_TABLES: 0
SELECT_FULL_JOIN: 0
SELECT_FULL_RANGE_JOIN: 0
SELECT_RANGE: 0
SELECT_RANGE_CHECK: 0
SELECT_SCAN: 1
SORT_MERGE_PASSES: 0
SORT_RANGE: 0
SORT_ROWS: 0
SORT_SCAN: 0
NO_INDEX_USED: 1
NO_GOOD_INDEX_USED: 0
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
1 row in set (0.00 sec)
Как видно из приведенного выше, вы получаете аналогичные данные, которые вы привыкли видеть из EXPLAINs и медленных журналов запросов, таких как время выполнения запроса, время блокировки, строки, отправленные / проверенные и т. Д. Например, в приведенном выше выводе мой запрос, полученный о 100 строк (строки 26-27), избегая создания временных таблиц (строки 28-29), не нужно было сортировать (строки 36-38), индекс не использовался (строка 39), и он работал около 121 мс (TIMER_END) -TIMER_START). Список предоставленных деталей не так обилен, как мог бы быть, но я думаю, что с более новыми выпусками этот список может увеличиться.
Если вы хотите читать дальше и вам интересно, как использовать Performance Schema для профилирования, посмотрите замечательную статью Джервина здесь !