Глава 21. MySQL Performance Schema

Схема Производительности обеспечивает способ осмотреть внутреннее выполнение сервера во времени выполнения. Это реализуется, используя PERFORMANCE_SCHEMA механизм хранения и performance_schema база данных. Схема Производительности фокусируется прежде всего на данных о производительности. Это отличается от INFORMATION_SCHEMA, который служит для контроля метаданных.

Схема Производительности следит за развитием событий сервера. "Событие" - что-либо, что сервер делает, который занимает время и был инструментован так, чтобы информация синхронизации могла быть собрана. Вообще, событие могло быть вызовом функции, ожиданием операционной системы, этапа выполнения SQL-оператора, такого как парсинг или сортировка, или весь оператор или группа операторов. В настоящий момент набор события обеспечивает доступ к информации о вызовах синхронизации (такой что касается взаимных исключений) файл и табличный ввод-вывод, блокировки таблицы, и т.д для сервера и для нескольких механизмов хранения.

События Schema производительности отличны от событий, записанных двоичному журналу сервера (которые описывают модификации данных), и события Event Scheduler (которые являются типом сохраненной программы).

События Schema производительности являются определенными для приведенного примера MySQL Server. В MySQL 5.6.9 и позже, таблицы Схемы Производительности считают локальными для сервера, и изменяется на них, не тиражируются или пишутся двоичному журналу. (Ошибка #14741537)

Текущие события доступны, так же как истории события и сводки. Это позволяет Вам определить, сколько времен инструментованные действия выполнялись и сколько времени они взяли. Информация о событии доступна, чтобы показать действия определенных потоков, или действие, связанное с определенными объектами, такими как взаимное исключение или файл.

PERFORMANCE_SCHEMA механизм хранения собирает данные события, используя "точки инструментария" в исходном коде сервера.

Собранные события сохранены в таблицах в performance_schema база данных. Эти таблицы могут быть запрошены, используя SELECT операторы как другие таблицы.

Конфигурация Схемы производительности может быть изменена динамически, обновляя таблицы в performance_schema база данных через SQL-операторы. Изменения конфигурации сразу влияют на сбор данных.

Таблицы в performance_schema база данных является представлениями или временными таблицами, которые не используют персистентного дискового хранения.

Контроль доступен на всех платформах, поддерживаемых MySQL.

Некоторые ограничения могли бы применяться: типы таймеров могли бы измениться на платформу. Инструменты, которые применяются к механизмам хранения, не могли бы быть реализованы для всех механизмов хранения. Инструментарий каждого стороннего механизма является ответственностью специалиста по обслуживанию механизма. См. также Раздел E.8, "Ограничения на Схему Производительности".

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

Активирование Схемы Производительности не вызывает изменений в поведении сервера. Например, это не заставляет планирование потоков изменяться, и это не вызывает планы выполнения запроса (как показано EXPLAIN) измениться.

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

Контроль сервера происходит непрерывно и незаметно с очень небольшими издержками. Активирование Схемы Производительности не делает сервер неприменимым.

Синтаксический анализатор неизменен. Нет никаких новых ключевых слов или операторов.

Выполнение серверного кода обычно продолжается, даже если Схема Производительности перестала работать внутренне.

Когда есть выбор между выполнением обработки во время набора события первоначально или во время извлечения события позже, приоритет дается созданию набора быстрее. Это - то, потому что набор является продолжающимся, тогда как извлечение по требованию и никогда не могло бы происходить вообще.

Легко добавить новые точки инструментария.

Инструментарий является имеющим версию. Если реализация инструментария изменится, то ранее инструментованный код будет продолжать работать. Это приносит пользу разработчикам сторонних плагинов, потому что не необходимо обновить каждый плагин, чтобы остаться синхронизируемым с последними изменениями Схемы Производительности.