Поделиться через

Настройка производительности и обслуживание баз данных в База данных Azure для MySQL — гибкий сервер с помощью sys_schema

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для MySQL — отдельный сервер База данных Azure для MySQL — гибкий сервер

Внимание

База данных Azure для MySQL один сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для MySQL гибкого сервера. Дополнительные сведения о миграции на гибкий сервер База данных Azure для MySQL см. в статье "Что происходит с одним сервером База данных Azure для MySQL?"

Схема performance_schema MySQL, которая стала впервые доступна в MySQL 5.5, предоставляет способ инструментирования многих важных ресурсов серверов, таких как выделение памяти, хранимые программы, блокировка метаданных и т. д. Однако performance_schema содержит более 80 таблиц. Для получения необходимой информации часто требуется объединение таблиц в performance_schema, а также таблицы из information_schema. В performance_schema и information_schema sys_schema предоставляется мощная коллекция пользовательских представлений в базе данных только для чтения и полностью включена в База данных Azure для MySQL гибком сервере версии 5.7.

Представления sys_schema.

В sys_schema есть 52 представления, каждое из которых имеет один из следующих префиксов:

  • Host_summary или IO. Задержки, связанные с операциями ввода и вывода.
  • InnoDB. Состояние и блокировки буфера InnoDB.
  • Memory. Использование памяти узлом и пользователями.
  • Schema. Информация, связанная со схемой, такая как автоматическое увеличение, индексы и т. д.
  • Statement. Информация об инструкциях SQL. Это может быть инструкция, выполнение которой привело к полному сканированию таблицы или длительному времени запроса.
  • User. Потребляемые ресурсы, сгруппированные по пользователям. Примерами являются операции ввода-вывода файлов, подключения и память.
  • Wait. События ожидания, сгруппированные по узлу или пользователю.

Теперь рассмотрим некоторые общие шаблоны использования sys_schema. Для начала мы сгруппируем шаблоны использования в две категории: настройка производительности и обслуживание базы данных.

Настройка производительности

sys.user_summary_by_file_io

Операции ввода-вывода являются наиболее ресурсоемкими операциями в базе данных. Мы можем узнать среднюю задержку операций ввода-вывода, запросив представление sys.user_summary_by_file_io. При использовании подготовленного хранилища по умолчанию размером 125 ГБ задержка ввода-вывода составляет около 15 секунд.

Задержка ввода-вывода: 125 ГБ.

Так как База данных Azure для MySQL гибкий сервер масштабирует операции ввода-вывода в отношении хранилища, после увеличения подготовленного хранилища до 1 ТБ задержка ввода-вывода уменьшается до 571 мс.

Задержка ввода-вывода: 1TB.

sys.schema_tables_with_full_table_scans

Несмотря на тщательное планирование, многие запросы могут по-прежнему привести к сканированию всей таблицы. Дополнительные сведения о типах индексов и их оптимизации см. в этой статье: устранение неполадок с производительностью запросов. Полное сканирование таблиц является ресурсоемким и снижает производительность вашей базы данных. Самый быстрый способ поиска таблиц с полным сканированием — запросить представление sys.schema_tables_with_full_table_scans.

Проверка полной таблицы.

sys.user_summary_by_statement_type

Чтобы устранить проблемы с производительностью базы данных, может быть полезно просто выявить события, происходящие внутри базы данных, а представление sys.user_summary_by_statement_type выведет необходимые сведения по типу инструкций.

Сводка по оператору.

В этом примере База данных Azure для MySQL гибкий сервер провел 53 минуты очистки журнала медленных запросов 44579 раз. Это занимает много времени и требует множества операций ввода-вывода. Вы можете уменьшить эту активность, отключив журнал медленных запросов либо уменьшив частоту внесения в него записей на портале Azure.

Обслуживание базы данных

sys.innodb_buffer_stats_by_table

[!ВАЖНО]

Запрос этого представления может повлиять на производительность. Устранение неполадок следует запланировать на нерабочее время.

Буферный пул InnoDB находится в памяти и является основным механизмом кэширования между СУБД и хранилищем. Размер буферного пула привязан к уровню производительности. Его можно изменить, только выбрав другой номер SKU продукта. Как и с памятью в операционной системе, старые страницы выгружаются, чтобы освободить место для новых данных. Чтобы узнать, какие таблицы используют больше всего памяти буферного пула InnoDB, можно запросить представление sys.innodb_buffer_stats_by_table.

Состояние буфера InnoDB.

На рисунке выше видно, что, за исключением системных таблиц и представлений, каждая таблица базы данных mysqldatabase033, которая размещает один из сайтов WordPress, занимает 16 КБ или 1 страницу данных в памяти.

Sys.schema_unused_indexes & sys.schema_redundant_indexes

Индексы являются эффективным инструментом повышения производительности чтения, однако они влекут дополнительные затраты, связанные с операциями вставки и хранением. sys.schema_unused_indexes и sys.schema_redundant_indexes предоставляют сведения об неиспользуемых или повторяющихся индексах.

Неиспользуемые индексы.

Избыточные индексы.

Заключение

Таким образом, sys_schema является мощным инструментом, который подходит и для настройки производительности, и для обслуживания базы данных. Не забудьте воспользоваться этой функцией в База данных Azure для MySQL гибком экземпляре сервера.

Следующие шаги

  • Чтобы найти ответы на самые важные вопросы либо опубликовать новый вопрос или ответ, посетите Stack Overflow.