Статьи

Новые PERFORMANCE_SCHEMA по умолчанию в MySQL 5.7.7

[Эта статья была написана Робертом Барабасом]

Я  подумал, что стоит потратить время на повторение настроек по умолчанию, связанных с новой схемой производительности, которые 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 для профилирования, посмотрите замечательную статью Джервина  здесь !