Понимание архитектуры MariaDB

Архитектура MariaDB частично отличается от архитектуры традиционных СУБД, таких как SQL Server. Здесь мы рассмотрим основные компоненты, которые должен знать новый DBA MariaDB. Мы также немного коснемся истории, потому что это может помочь понять философию MariaDB и определенные решения при проектировании.

Этот раздел представляет собой обзор важнейших компонентов. Более подробная информация содержится в конкретных разделах данного руководства по миграции или на других страницах базы знаний MariaDB (см. ссылки, разбросанные по тексту).

Двигатели хранения

MariaDB была создана на основе исходного кода MySQL в 2008 году. Поэтому ее история начинается с MySQL.

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

Веб-технологии быстро развивались, и то же самое происходило с MySQL. Открытый исходный код очень помог в этом отношении, потому что сообществу были необходимы функциональности, которые в то время не поддерживались.

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

Один из первых плагинов, разработанных сторонними разработчиками, был InnoDB. Он очень быстрый и добавляет две важные функции, которые иначе не поддерживаются: транзакции и внешние ключи.

Обратите внимание, что когда MariaDB просит двигатель хранения записать или прочитать строку, двигатель хранения теоретически может сделать всё что угодно. Это привело к созданию очень интересных альтернативных двигателей, таких как BLACKHOLE (который не записывает и не считывает данные, действуя как файл /dev/null в Linux) или CONNECT (который может читать и записывать в файлы, записанные в различных форматах, или в удаленные СУБД, или в некоторые другие специальные источники данных).

В настоящее время InnoDB является по умолчанию двигателем хранения MariaDB и является лучшим выбором для большинства случаев использования. Но для конкретных потребностей иногда желательно использовать другой двигатель хранения. В случае сомнений относительно наилучшего двигателя хранения для конкретного случая, ознакомьтесь со страницей Выбор правильного двигателя хранения.

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

Обратите внимание, что в одной транзакции можно использовать таблицы с разными двигателями хранения (даже если некоторые двигатели не являются транзакционными). Можно даже использовать разные двигатели в одном запросе, например, с операциями JOIN и подзапросами.

Двигатель хранения по умолчанию можно изменить, изменив переменную default_storage_engine. Разный по умолчанию можно указать для временных таблиц, установив default_tmp_storage_engine. MariaDB использует Aria для системных таблиц и временных таблиц, создаваемых внутри для хранения промежуточных результатов запроса.

InnoDB

Стоит уделить больше внимания InnoDB, двигателю хранения по умолчанию.

Первичный ключ и индексы

Первичные ключи InnoDB всегда эквивалентны кластеризованным индексам SQL Server. Другими словами, таблица InnoDB всегда упорядочена по первичному ключу.

Если у таблицы InnoDB нет определенного пользователем первичного ключа, первым UNIQUE индексом, столбцы которого все NOT NULL используется в качестве первичного ключа. Если такого индекса нет, таблица будет иметь _кластеризованный индекс_. Здесь терминология может быть немного запутанной для пользователей SQL Server и других СУБД. Кластеризованный индекс в InnoDB — это значение из 6 байт, которое добавляется к таблице. Этот индекс и его значения полностью невидимы для пользователей. Важно отметить, что кластеризованные индексы управляются глобальным мьютексом, что значительно снижает их масштабируемость.

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

Некоторые последствия этих решений по проектированию следующие:

• По соображениям производительности значение первичного ключа следует вставлять в порядке возрастания. Другими словами, последнее вставленное значение должно быть наибольшим. Этот порядок обычно соблюдается при вставке значений в AUTO_INCREMENT первичный ключ. Причина в том, что вставка значений в середину упорядоченной структуры данных медленнее, если только они не помещаются в существующие пробелы. Если мы вставляем значения первичного ключа случайным образом, InnoDB часто должен переупорядочивать страницы, чтобы освободить место для новых данных.
• Большой первичный ключ означает, что все вторичные индексы также большие.
• Запрос по первичному ключу потребует одного поиска. Запрос по вторичному индексу, который также считывает столбцы, не содержащиеся в индексе, потребует одного поиска в индексе плюс еще один поиск для каждой строки, удовлетворяющей условию индекса.
• Не следует явно включать первичный ключ во вторичный индекс. Если это сделать, столбец первичного ключа будет дублироваться в индексе.

Пространства таблиц

Для InnoDB _пространство таблиц_ — это файл, содержащий данные (а не группа файлов, как в SQL Server). Типы пространств таблиц:

• Системное пространство таблиц.
• Пространства таблиц по файлу на таблицу.
• Временные пространства таблиц.

Системное пространство таблиц хранится в файле ibdata. Оно содержит информацию, используемую InnoDB внутри, например, сегменты отката, а также некоторые системные таблицы. Исторически системное пространство таблиц также содержало все таблицы, созданные пользователем. В современных версиях MariaDB таблица создается в системном пространстве таблиц только если переменная innodb_file_per_table установлена в 0 в момент создания таблицы. По умолчанию innodb_file_per_table равно 1.

Таблицы, созданные, пока innodb_file_per_table=1 записываются в свои пространства таблиц. Это .ibd файлы.

Начиная с MariaDB 10.2, временные таблицы записываются во временные пространства таблиц, что означает ibtmp* файлы. Ранее они создавались в системном пространстве таблиц или в пространствах таблиц по файлу на таблицу в зависимости от значения innodb_file_per_table, как и обычные таблицы. Временные пространства таблиц, если они присутствуют, удаляются при запуске MariaDB.

Важно помнить, что пространства таблиц никогда не уменьшаются. Если пространство таблиц по файлу на таблицу становится слишком большим, удаление данных не восстановит место. Вместо этого необходимо создать новую таблицу и скопировать данные. Затем старая таблица будет удалена. Если системное пространство таблиц становится слишком большим, единственным решением является перенос данных в новую установку MariaDB.

Журналы транзакций

В SQL Server журнал транзакций содержит как журнал отката, так и журнал повтора. Обычно у нас есть только один журнал транзакций.

В MariaDB журнал отката и журнал повтора хранятся отдельно. По умолчанию журнал повтора записывается в два файла, называемые ib_logfile0 и ib_logfile1. Журнал отката по умолчанию записывается в _системное пространство таблиц_, которое находится в файле ibdata1. Однако его можно записать в отдельные файлы в указанном каталоге.

MariaDB не предоставляет возможности проверки содержимого журналов транзакций. Однако можно проверить бинарный журнал.

Журналы транзакций InnoDB записываются циклически: их размер обычно фиксирован, и когда достигается конец, InnoDB продолжает запись с начала. Однако, если выполняются очень длинные транзакции, InnoDB не может перезаписать старые данные, поэтому ему приходится увеличивать размер журнала.

Пул буферов InnoDB

MariaDB не имеет центрального пула буферов. Каждый двигатель хранения может или не может иметь пул буферов. Пул буферов InnoDB обычно выделяется большой объем памяти. См. Распределение памяти в MariaDB.

MariaDB не имеет расширения, подобного расширению пула буферов SQL Server.

Часть пула буферов называется буфером изменений. Он содержит грязные страницы, которые были изменены в памяти и еще не записаны на диск.

Фоновые потоки InnoDB

InnoDB имеет фоновые потоки, которые отвечают за запись грязных страниц из буфера изменений в пространства таблиц. Они не влияют напрямую на задержку запросов, но очень важны для производительности.

SHOW ENGINE InnoDB STATUS отображает информацию о них в разделе BACKGROUND THREAD. Их также можно увидеть, используя таблицу threads в performance_schema.

Сброс InnoDB аналогичен _ленивым записям_ и _контрольным точкам_ в SQL Server. У него нет аналога _быстрым записям_.

Дополнительную информацию можно найти в Сброс страниц InnoDB и Очистка InnoDB.

Контрольные суммы и буфер двойной записи

Страницы InnoDB имеют контрольные суммы. После записи страниц на диск InnoDB проверяет соответствие контрольных сумм. Алгоритм контрольной суммы определяется переменной innodb_checksum_algorithm. Ознакомьтесь с документацией по переменной для понимания ее последствий для производительности, обратной совместимости и шифрования.

В случае сбоя системы, аппаратного сбоя или отключения электропитания страница могла быть частично записана на диск. Для некоторых страниц это приводит к катастрофе. Поэтому InnoDB записывает важные страницы на диск дважды. Сначала записывается резервная копия нового варианта страницы. Затем старая страница перезаписывается. Резервные копии записываются в файл, называемый _буфером двойной записи_.

• Если событие предотвращает запись первой страницы, старый вариант страницы по-прежнему будет доступен.
• Если событие предотвращает полное перезапись старой страницы новым вариантом, страницу все равно можно восстановить, используя буфер двойной записи.

Буфер двойной записи можно отключить, используя переменную innodb_doublewrite, но это обычно не приносит значительных преимуществ производительности. Местоположение буфера двойной записи можно изменить с помощью innodb_doublewrite_file.

Aria

Даже если мы создаем только таблицы InnoDB, мы косвенно используем Aria двумя способами:

• Для системных таблиц.
• Для внутренних временных таблиц.

Aria — это не транзакционный движок хранения данных. По умолчанию он безопасен при сбоях, что означает, что все изменения данных записываются и синхронизируются в журнал предварительной записи, и их всегда можно восстановить в случае сбоя.

Aria кэширует индексы в кэш страниц. Данные напрямую не кэшируются Aria, поэтому важно, чтобы базовый файловая система кэшировала чтение и запись.

Размер кэша страниц определяется системной переменной aria_pagecache_buffer_size. Чтобы узнать, достаточно ли он большой, мы можем проверить долю свободных страниц (соотношение между Aria_pagecache_blocks_used и Aria_pagecache_blocks_unused) и долю промахов кэша (соотношение между Aria_pagecache_read_requests и Aria_pagecache_reads).

Доля грязных страниц — это отношение между Aria_pagecache_blocks_used и Aria_pagecache_blocks_not_flushed — показывает, достаточно ли большой файл журнала.

Размер журнала Aria определяется значением aria_log_file_size.

Базы данных

MariaDB не поддерживает концепцию схемы. В MariaDB SQL, схема и схемы являются синонимами для базы данных и баз данных.

Когда пользователь подключается к MariaDB, он не подключается к определенной базе данных. Вместо этого он может получить доступ к любой таблице, для которой у него есть разрешения. Однако есть понятие базы данных по умолчанию, см. ниже.

База данных — это контейнер для объектов базы данных, таких как таблицы и представления. База данных служит следующим целям:

• База данных — это пространство имен.
• База данных — это логический контейнер для разделения объектов.
• База данных имеет набор символов и сортировку по умолчанию, которые наследуются их таблицами.
• Разрешения могут быть назначены на всю базу данных, чтобы упростить управление разрешениями.
• Физические файлы данных хранятся в каталоге с тем же именем, что и база данных, к которой они относятся.

Системные базы данных

MariaDB имеет следующие системные базы данных:

• mysql предназначена только для внутреннего использования и не должна читаться или записываться напрямую.
• information_schema содержит всю информацию, которую можно найти в information_schema SQL Server, и более того. Однако, в то время как information_schema SQL Server — это схема, содержащая информацию о локальной базе данных, information_schema в MariaDB — это база данных, которая содержит информацию обо всех базах данных.
• performance_schema содержит информацию о работе MariaDB. По умолчанию она отключена. Для включения необходимо установить системную переменную performance_schema в 1 и перезапустить MariaDB.

База данных по умолчанию

При подключении к MariaDB пользователь может указать базу данных по умолчанию. Базу данных по умолчанию также можно указать или изменить позже с помощью команды USE.

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

Например, следующие два фрагмента эквивалентны:

SELECT * FROM my_database.my_table;

-- is equivalent to:
USE my_database;
SELECT * FROM my_table;

Даже если база данных по умолчанию указана, к таблицам из других баз данных можно получить доступ, указав их полные имена:

-- this query joins my_database.my_table to your_database.your_table
USE my_database;
SELECT m.*
    FROM my_table m
    JOIN your_database.your_table y
        ON m.xyz = y.xyz;

MariaDB имеет функцию DATABASE() для определения текущей базы данных:

SELECT DATABASE();

Процедуры и триггеры не наследуют базу данных по умолчанию из сеанса, ни от вызывающей процедуры. В этом контексте базой данных по умолчанию является база данных, содержащая процедуру. USE может быть использована для её изменения. База данных по умолчанию будет действительной только до конца процедуры.

Журнал двоичных логов

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

Вместо этого ей нужен глобальный механизм для регистрации изменений, применяемых к данным. Этот механизм — журнал двоичных логов, часто сокращаемый до binlog.

Журнал двоичных логов может быть записан в следующих форматах:

• STATEMENT записывает SQL-команды, изменяющие данные;
• ROW записывает ссылку на изменённые строки (обычно первичный ключ) и новые значения, которые были добавлены или изменены, в двоичном формате.
• MIXED — это сочетание вышеуказанных форматов. Это означает, что ROW используется для команд, которые могут быть безопасно записаны таким образом (см. ниже), а STATEMENT используется в других случаях. Это формат по умолчанию начиная с MariaDB 10.2.

В большинстве случаев STATEMENT медленнее, потому что SQL-команда должна быть повторно выполнена репликой, и потому что некоторые команды могут привести к разному результату на реплике (подумайте о запросах, использующих LIMIT без ORDER BY, или о функции CURRENT_TIMESTAMP()). Но есть исключения, и, кроме того, команды DDL всегда записываются как STATEMENT, чтобы избежать заполнения журнала двоичных логов. Поэтому журнал двоичных логов может содержать как записи ROW, так и STATEMENT.

См. Форматы журналов двоичных логов.

Журнал двоичных логов позволяет:

• репликация, если она включена на основном сервере;
• преобразование реплики в основной сервер, если она включена на этой реплике;
• инкрементные резервные копии;
• просмотр данных, как они были в прошлом (возврат к состоянию);
• восстановление резервной копии и повторное применение журнала двоичных логов, за исключением изменения данных, которое вызвало проблемы (ошибка пользователя, ошибка приложения, SQL-инъекция);
• Capture Data Changes (CDC) путем потоковой передачи журнала двоичных логов в такие технологии, как Apache Kafka.

Если вы не планируете использовать ни одну из этих функций на сервере, можно отключить журнал двоичных логов, чтобы немного улучшить производительность.

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

См. также Обзор репликации MariaDB для пользователей SQL Server и Обзор резервного копирования MariaDB для пользователей SQL Server для лучшего понимания того, как используется журнал двоичных логов.

Плагины

Движки хранения данных — это особый тип плагинов. Но существуют и другие. Например, плагины могут добавлять методы авторизации, новые функции, синтаксис SQL, функции, информативные таблицы и многое другое.

Плагин может добавить некоторые переменные сервера и некоторые переменные состояния. Переменные сервера могут быть использованы для настройки плагина, а переменные состояния могут быть использованы для мониторинга его активности и состояния. Эти переменные обычно используют имя плагина в качестве префикса. Например, InnoDB имеет переменную сервера innodb_buffer_pool_size для настройки размера своего буфера, и переменную состояния Innodb_pages_read, которая указывает количество страниц памяти, считанных из буфера.

Категория системных переменных базы знаний MariaDB содержит страницы для системных и переменных состояния, связанных с различными плагинами.

Многие плагины устанавливаются по умолчанию или доступны, но не установлены по умолчанию. Их можно установить или удалить во время работы с помощью SQL-команд, таких как INSTALL PLUGIN, UNINSTALL PLUGIN и других; см. SQL-команды для плагинов. Плагины сторонних разработчиков могут быть доступны для установки, просто скопировав их в plugin_dir.

Важно отметить, что у разных плагинов могут быть разные уровни зрелости. Можно предотвратить установку плагинов, которые мы не считаем готовыми к использованию в производстве, установив системную переменную plugin_maturity. Для плагинов, которые распространяются с MariaDB, уровень зрелости определяется командой MariaDB на основе сообщений об ошибках и их исправлений.

Некоторые плагины разработаны сторонними компаниями. Некоторые плагины сторонних разработчиков включены в официальные дистрибутивы MariaDB — те, что доступны на mariadb.org.

В MariaDB каждый метод авторизации (включая стандартный) предоставляется плагином авторизации. Пользователь может быть обязан использовать определенный плагин авторизации. Это даёт нам большую гибкость и контроль. Пользователям Windows может быть интересен плагин gsapi (который поддерживает авторизацию Windows, Kerberos и NTLM) и named_pipe (который использует имитацию именованных каналов).

Другие полезные плагины включают userstat, который включает статистику использования ресурсов и таблиц, и METADATA_LOCK_INFO, который предоставляет информацию о блокировках метаданных.

Пул потоков

MariaDB поддерживает пул потоков. Он работает по-разному на UNIX и Windows. На Windows он включен по умолчанию, и его реализация очень похожа на SQL Server. Он использует Windows API CreateThreadpool.

Если мы не используем пул потоков, MariaDB будет использовать традиционный метод обработки подключений. Он состоит из использования отдельного потока для каждого клиентского подключения. Создание нового потока имеет затраты по времени процессора. Чтобы уменьшить эти затраты, после разрыва подключения клиента поток может сохраняться в течение некоторого времени в кэше потоков.

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

Настройка

MariaDB имеет множество параметров, которые контролируют поведение сервера. Эти параметры можно установить при запуске mysqld (параметры mysqld), и подавляющее большинство из них также доступны как системные переменные сервера. Эти параметры можно классифицировать следующим образом:

• Динамические или статические;
• Глобальные, сеансовые или оба.

Обратите внимание, что системные переменные сервера не следует путать с переменными, определенными пользователем. Последние не используются для настройки MariaDB.

Файлы конфигурации

MariaDB может использовать несколько файлов конфигурации. Файлы конфигурации ищутся в нескольких местах, включая пользовательский каталог, и, если они присутствуют, все они читаются и используются. Они читаются в согласованном порядке. Эти места зависят от операционной системы; см. Расположение файлов конфигурации по умолчанию. Можно указать MariaDB, какие файлы следует читать; см. Глобальные параметры, связанные с файлами конфигурации.

В Linux по умолчанию файлы конфигурации называются my.cnf. В Windows по умолчанию файлы конфигурации могут называться my.ini или my.cnf. Первый вариант используется чаще.

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

Содержимое каждого файла конфигурации организовано по группам параметров. MariaDB Server и клиентские программы считывают разные группы. Считываемые группы также зависят от версии MariaDB. Подробности см. в Группы параметров. Чаще всего, группы [server] или [mysqld] используются для хранения всех настроек сервера. Группа [client-server] может использоваться для параметров, общих для сервера и клиентов (например, используемый порт), чтобы избежать многократного повторения этих переменных.

Динамические и статические переменные

Динамические переменные имеют значение, которое может быть изменено во время выполнения с помощью оператора SQL SET. Статические переменные имеют значение, которое устанавливается при запуске (см. ниже) и не может быть изменено без перезапуска.

На странице Системные переменные сервера указано, являются ли переменные динамическими или статическими.

Область действия

Глобальная системная переменная — это переменная, которая влияет на общее поведение MariaDB. Например, innodb_buffer_pool_size определяет размер буфера пула InnoDB, который используется операциями чтения и записи независимо от того, какой пользователь их выполнил. Сеансовая системная переменная — это переменная, которая влияет на поведение MariaDB для текущего подключения; изменение ее не повлияет на других подключенных пользователей или будущие подключения текущего пользователя.

Переменная может существовать как в глобальной, так и в сеансовой областях действия. В этом случае значение сеанса влияет на текущее подключение. Когда пользователь подключается, текущее глобальное значение копируется в сеансовую область действия. Изменение глобального значения впоследствии не повлияет на существующие подключения.

На странице Системные переменные сервера указана область действия каждой переменной.

Глобальные переменные и некоторые сеансовые переменные могут быть изменены только пользователем с привилегием SUPER (обычно root).

Синтаксис

Чтобы увидеть значение системной переменной:

-- global variables:
SELECT @@global.variable_name;
-- session variables:
SELECT @@session.variable_name;
-- or just use the shortcut:
SELECT @@variable_name;

Более длинный синтаксис, который в основном полезен для получения нескольких переменных, использует тот же синтаксис шаблона, что и оператор LIKE:

-- global variables whose name starts with 'innodb':
SHOW GLOBAL VARIABLES LIKE 'innodb%';
-- session variables whose name starts with 'innodb':
SHOW SESSION VARIABLES LIKE 'innodb%';
SHOW VARIABLES LIKE 'innodb%';

Чтобы изменить глобальное или сеансовое значение динамической переменной:

SET @@global.variable_name = 'new 'value';
SET @@session.variable_name = 'new 'value';

Обратите внимание, что если мы изменим глобальную переменную таким образом, новое значение будет потеряно при перезапуске сервера. Поэтому, скорее всего, нам нужно изменить значение и в файле конфигурации.

Для получения дополнительной информации см.:

• Оператор SET.
• Оператор SHOW VARIABLES.

Установка системных переменных с параметрами запуска

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

Общее правило состоит в том, что каждая глобальная переменная может быть передана в качестве аргумента mysqld путем добавления префикса -- к ее имени и замены всех вхождений _ на - в ее имени.

Например, чтобы передать bind_address в качестве аргумента запуска:

mysqld --bind-address=127.0.0.1

Отладка конфигурации

Опечатка переменной может помешать запуску MariaDB. Мы не можем установить переменную, которая не существует в используемой версии MariaDB. В таких случаях ошибка записывается в файл журнала ошибок.

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

mysqld --print-defaults

Переменные состояния

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

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

• Глобальной, что означает, что значение относится к какой-либо активности MariaDB.
• Сеансовой, что означает, что значение измеряет активность, происходящую в текущем сеансе.

Многие переменные состояния существуют в обеих областях действия. Например, Cpu_time на глобальном уровне указывает, сколько времени процессор использовался процессом MariaDB (включая все сеансы пользователей и все фоновые потоки). На уровне сеанса она указывает, сколько времени процессор использовался текущим сеансом.

Значения переменных состояния, созданных плагином, обычно имеют префикс с именем плагина.

Оператор SHOW STATUS выводит значения переменных состояния, соответствующие определенному шаблону.

-- Show all InnoDB global status variables
SHOW GLOBAL STATUS LIKE 'innodb%';
-- Show all InnoDB session status variables
SHOW SESSION STATUS LIKE 'innodb%';
SHOW STATUS LIKE 'innodb%';
-- Show global variables that contain the "size" substring:
SHOW GLOBAL STATUS LIKE '%size%';

Значения некоторых переменных состояния сбрасываются при выполнении FLUSH STATUS. Возможный способ использования:

DELIMITER ||
BEGIN NOT ATOMIC
SET @i = 0;
WHILE @i < 60 DO
    SHOW GLOBAL STATUS LIKE 'Com_select';
    FLUSH STATUS;
    DO SLEEP(1);
    SET @i = @i + 1;
END WHILE;
END ||