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

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

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

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

Рассмотрим следующие запросы:

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_TEXT, который содержит исходный 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      |
+----------------------------------------------------------------------+