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

Анализатор также используется функциями STATEMENT_DIGEST_TEXT() и STATEMENT_DIGEST(), которые приложения могут вызывать для вычисления нормализованной сводки запроса и значения хэша сводки соответственно из SQL-запроса.

Значение системной переменной max_digest_length определяет максимальное количество байтов, доступное в сессии для вычисления нормализованных сводок запросов. После использования этого объёма памяти во время вычисления сводки происходит усечение: дальнейшие токены из разобранного запроса не собираются и не участвуют в вычислении значения сводки. Запросы, отличающиеся только после указанного количества байтов разбора токенов, производят одинаковую нормализованную сводку запроса и считаются одинаковыми при сравнении или агрегировании для статистики сводок.

После вычисления нормализованного запроса вычисляется значение хэша SHA-256. Кроме того:

Нормализация запроса преобразует текст запроса в более стандартизированное представление сводки, сохраняя общую структуру запроса и удаляя информацию, не существенную для структуры:

Рассмотрим эти запросы:

SELECT * FROM orders WHERE customer_id=10 AND quantity>20
SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100

Для нормализации этих запросов анализатор заменяет значения данных на ? и корректирует пробелы. Оба запроса приводят к одинаковой нормализованной форме и, следовательно, считаются “одинаковыми”:

SELECT * FROM orders WHERE customer_id = ? AND quantity > ?

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

Теперь рассмотрим эти запросы:

SELECT * FROM customers WHERE customer_id = 1000
SELECT * FROM orders WHERE customer_id = 1000

В этом случае нормализованные запросы отличаются, потому что идентификаторы объектов различаются:

SELECT * FROM customers WHERE customer_id = ?
SELECT * FROM orders WHERE customer_id = ?

Если нормализация производит запрос, превышающий доступное пространство в буфере сводки (как определяется переменной max_digest_length), происходит усечение, и текст завершается “...”. Длинные нормализованные запросы, отличающиеся только частью, следующей за “...”, считаются одинаковыми. Рассмотрим эти запросы:

SELECT * FROM mytable WHERE cola = 10 AND colb = 20
SELECT * FROM mytable WHERE cola = 10 AND colc = 20

Если отсечение происходит сразу после AND, оба запроса имеют эту нормализованную форму:

SELECT * FROM mytable WHERE cola = ? AND ...

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

В схеме производительности обработка сводок операторов включает следующие элементы:

Некоторые таблицы производительности содержат столбец, хранящий исходные SQL-операторы, из которых вычисляются сводки:

Максимальное пространство для отображения операторов по умолчанию составляет 1024 байта. Для изменения этого значения установите системную переменную performance_schema_max_sql_text_length при запуске сервера. Изменения влияют на объём памяти, необходимый для всех указанных столбцов.

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

Таблица сводки операторов events_statements_summary_by_digest предоставляет профиль операторов, выполненных сервером. Она показывает, какие типы операторов выполняет приложение и как часто. Разработчик приложения может использовать эту информацию вместе с другой информацией в таблице, чтобы оценить характеристики производительности приложения. Например, столбцы таблицы, отображающие время ожидания, время блокировки или использование индексов, могут выделить типы запросов, которые неэффективны. Это даёт разработчику понимание, какие части приложения требуют внимания.

Таблица сводки операторов events_statements_summary_by_digest имеет фиксированный размер. По умолчанию схема производительности оценивает размер при запуске. Чтобы явно указать размер таблицы, установите системную переменную performance_schema_digests_size при запуске сервера. Если таблица заполнится, схема производительности сгруппирует операторы, у которых значения SCHEMA_NAME и DIGEST не соответствуют существующим значениям в таблице, в специальной строке со значениями SCHEMA_NAME и DIGEST, установленным на NULL. Это позволяет посчитать все операторы. Однако, если специальная строка учитывает значительный процент выполненных операторов, может быть целесообразно увеличить размер таблицы сводки, увеличив значение performance_schema_digests_size.

Для приложений, генерирующих очень длинные заявления, которые различаются только в конце, увеличение значения max_digest_length позволяет вычислять дайджесты, которые различат заявления, которые в противном случае агрегировались бы в один и тот же дайджест. И наоборот, уменьшение значения max_digest_length заставляет сервер выделять меньше памяти для хранения дайджестов, но увеличивает вероятность того, что более длинные заявления агрегируются в один и тот же дайджест. Администраторы должны помнить, что более крупные значения приводят к соответствующему увеличению потребностей в памяти, особенно для рабочих нагрузок, включающих большое количество одновременных сессий (сервер выделяет max_digest_length байтов на сессию).

Как описано ранее, нормализованные дайджесты заявлений, вычисляемые анализатором, ограничены максимальным значением max_digest_length байтов, в то время как нормализованные дайджесты заявлений, хранящиеся в Performance Schema, используют performance_schema_max_digest_length байтов. Следующие соображения по использованию памяти относятся к относительным значениям max_digest_length и performance_schema_max_digest_length:

Так как таблицы событий заявлений Performance Schema могут хранить много дайджестов, установка performance_schema_max_digest_length меньше, чем max_digest_length, позволяет администраторам сбалансировать эти факторы:

Настройка performance_schema_max_digest_length не зависит от сессии, она относится к каждому заявлению, и сессия может хранить несколько заявлений в таблице events_statements_history. Типичное число заявлений в этой таблице составляет 10 на сессию, поэтому каждая сессия потребляет в 10 раз больше памяти, указанной значением performance_schema_max_digest_length, только для этой таблицы.

Также существует множество заявлений (и дайджестов), собираемых глобально, особенно в таблице events_statements_history_long. И здесь N хранимых заявлений потребляет N раз больше памяти, указанной значением performance_schema_max_digest_length.

Для оценки количества памяти, используемой для хранения и вычисления дайджестов SQL-заявлений, используйте оператор SHOW ENGINE PERFORMANCE_SCHEMA STATUS или отслеживайте эти инструменты:

mysql> SELECT NAME
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE '%.sqltext';
+------------------------------------------------------------------+
| NAME                                                             |
+------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.sqltext      |
| memory/performance_schema/events_statements_current.sqltext      |
| memory/performance_schema/events_statements_history_long.sqltext |
+------------------------------------------------------------------+

mysql> SELECT NAME
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'memory/performance_schema/%.tokens';
+----------------------------------------------------------------------+
| NAME                                                                 |
+----------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.tokens           |
| memory/performance_schema/events_statements_current.tokens           |
| memory/performance_schema/events_statements_summary_by_digest.tokens |
| memory/performance_schema/events_statements_history_long.tokens      |
+----------------------------------------------------------------------+

Performance Schema использует выборку заявлений для сбора репрезентативных заявлений, которые генерируют каждое значение дайджеста в таблице events_statements_summary_by_digest. Эти столбцы хранят информацию о выборке заявлений: QUERY_SAMPLE_TEXT (текст заявления), QUERY_SAMPLE_SEEN (время, когда было замечено заявление) и QUERY_SAMPLE_TIMER_WAIT (время ожидания или выполнения заявления). Performance Schema обновляет все три столбца каждый раз, когда выбирает пример заявления.

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

По умолчанию performance_schema_max_digest_sample_age составляет 60 секунд (1 минута). Чтобы изменить скорость, с которой выборочные заявления «исчезают» из-за возраста, увеличьте или уменьшите значение. Чтобы отключить часть политики повторного выбора, основанную на возрасте, установите performance_schema_max_digest_sample_age в 0.