Настройка производительности и обслуживание баз данных в База данных 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.

Views of 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 секунд.

IO latency: 125 GB.

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

IO latency: 1TB.

sys.schema_tables_with_full_table_scans

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

Full table scans.

sys.user_summary_by_statement_type

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

Summary by statement.

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

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

sys.innodb_buffer_stats_by_table

[!ВАЖНО]

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

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

InnoDB buffer status.

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

Sys.schema_unused_indexes & sys.schema_redundant_indexes

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

Unused indexes.

Redundant indexes.

Заключение

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

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

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