Когда анализатор получает 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.