Spec-Zone .ru
спецификации, руководства, описания, API

14.2.4.3. InnoDB INFORMATION_SCHEMA таблицы

INFORMATION_SCHEMA функция MySQL, которая помогает Вам контролировать действие сервера, чтобы диагностировать проблемы производительности и емкость. Несколько InnoDB-связанные INFORMATION_SCHEMA таблицы (INNODB_CMP, INNODB_CMP_RESET, INNODB_CMPMEM, INNODB_CMPMEM_RESET, INNODB_TRX, INNODB_LOCKS и INNODB_LOCK_WAITS) содержите живую информацию о сжатых таблицах InnoDB, сжатом пуле буферов InnoDB, все транзакции, в настоящий момент выполняющиеся в InnoDB, блокировки, которые транзакции содержат и те, которые блокируют транзакции, ожидающие доступа к ресурсу (таблица или строка).

Этот раздел описывает InnoDB-связанные таблицы Информационной схемы и показывает некоторые примеры их использования.

14.2.4.3.1. Таблицы Информационной схемы о Сжатии

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

14.2.4.3.1.1. INNODB_CMP и INNODB_CMP_RESET

INNODB_CMP и INNODB_CMP_RESET таблицы содержат информацию о статусе об операциях, связанных со сжатыми таблицами, которые покрываются Разделом 5.4.6, "Работающий с InnoDB Сжатые Таблицы". Сжатый размер страницы находится в столбце PAGE_SIZE.

У этих двух таблиц есть идентичное содержание, но читающий из INNODB_CMP_RESET сбрасывает статистику по операциям сжатия и несжатия. Например, если Вы архивируете вывод INNODB_CMP_RESET каждые 60 минут Вы видите статистику в течение каждого почасового периода. Если Вы контролируете вывод INNODB_CMP (удостоверяющийся никогда не читать INNODB_CMP_RESET), Вы видите накопленную статистику, так как InnoDB был запущен.

Для табличного определения см. Таблицу 19.1, "Столбцы INNODB_CMP и INNODB_CMP_RESET".

14.2.4.3.1.2. INNODB_CMPMEM иINNODB_CMPMEM_RESET

INNODB_CMPMEM и INNODB_CMPMEM_RESET таблицы содержат информацию о статусе на сжатых страницах, которые находятся в пуле буферов. Пожалуйста, консультируйтесь с Разделом 5.4.6, "Работающий с InnoDB Сжатые Таблицы" для дополнительной информации о сжатых таблицах и использовании пула буферов. INNODB_CMP и INNODB_CMP_RESET таблицы должны обеспечить более полезную статистику по сжатию.

Внутренние Детали

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

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

Для табличного определения см. Таблицу 19.3, "Столбцы INNODB_CMPMEM и INNODB_CMPMEM_RESET".

14.2.4.3.1.3. Используя Таблицы Информационной схемы Сжатия

Пример 14.2. Используя Таблицы Информационной схемы Сжатия

Следующее является демонстрационным выводом от базы данных, которая содержит сжатые таблицы (см. Раздел 5.4.6, "Работающий с InnoDB Сжатые Таблицы", INNODB_CMP, INNODB_CMP_PER_INDEX, и INNODB_CMPMEM).

Следующая таблица показывает содержание INFORMATION_SCHEMA.INNODB_CMP при легкой рабочей нагрузке. Единственный сжатый размер страницы, который содержит пул буферов, составляет 8 K Сжатия, или распаковка страниц использовала меньше чем секунда со времени, статистические данные были сброшены, потому что столбцы COMPRESS_TIME и UNCOMPRESS_TIME нуль.

размер страницы операция в секунду сжатия операция в секунду сжатия хорошо время сжатия распакуйте операцию в секунду распакуйте время
1024 0 0 0 0 0
2048 0 0 0 0 0
4096 0 0 0 0 0
8192 1048 921 0 61 0
16384 0 0 0 0 0

Согласно INNODB_CMPMEM, есть 6169, сжимал страницы 8 Кбит в пуле буферов. Единственный другой выделенный размер блока составляет 64 байта. Самое маленькое PAGE_SIZE в INNODB_CMPMEM используется для дескрипторов блока тех сжатых страниц, для которых никакая несжатая страница не существует в пуле буферов. Мы видим, что есть 5910 таких страниц. Косвенно, мы видим, что 259 (6169-5910) сжатые страницы также существуют в пуле буферов в несжатой форме.

Следующая таблица показывает содержание INFORMATION_SCHEMA.INNODB_CMPMEM при легкой рабочей нагрузке. Некоторая память неприменима из-за фрагментации средства выделения памяти для сжатых страниц: SUM(PAGE_SIZE*PAGES_FREE)=6784. Это - то, потому что маленькие запросы выделения памяти выполняются, разделяя большие блоки, запускаясь с 16 K блоков, которые выделяются от основного пула буферов, используя систему выделения приятеля. Фрагментация - этот низко, потому что некоторые выделенные блоки были перемещены (скопированные), чтобы сформировать большие смежные свободные блоки. Это копирование SUM(PAGE_SIZE*RELOCATION_OPS) байты использовали меньше чем секунда (SUM(RELOCATION_TIME)=0).

размер страницы страницы используются свободные страницы операция в секунду перемещения время перемещения
64 5910 0 2436 0
128 0 1 0 0
256 0 0 0 0
512 0 1 0 0
1024 0 0 0 0
2048 0 1 0 0
4096 0 1 0 0
8192 6169 0 5 0
16384 0 0 0 0

14.2.4.3.2. Таблицы Информационной схемы о Транзакциях

Три InnoDB-связанных таблицы Информационной схемы облегчают контролировать транзакции и диагностировать возможные проблемы блокировки. Эти три таблицы INNODB_TRX, INNODB_LOCKS, и INNODB_LOCK_WAITS.

  • INNODB_TRX

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

    Для табличного определения см. Таблицу 19.4,"INNODB_TRX Столбцы".

  • INNODB_LOCKS

    Каждая транзакция в InnoDB, который ожидает другой транзакции, чтобы выпустить блокировку (INNODB_TRX.TRX_STATE='LOCK WAIT') блокируется точно одним "запросом блокировки блокирования". Тот запрос блокировки блокирования для блокировки строки или блокировки таблицы, сохраненной другой транзакцией в несовместимом режиме. Ожидание или блокированная транзакция не могут продолжиться, пока другая транзакция не фиксирует или откатывает, таким образом выпуская требуемую блокировку. Для каждой блокированной транзакции, INNODB_LOCKS содержит одну строку, которая описывает каждую блокировку, которую транзакция запросила, и которого это ожидает. INNODB_LOCKS также содержит одну строку для каждой блокировки, которая блокирует другую транзакцию, безотносительно состояния транзакции, которая содержит блокировку ('RUNNING', 'LOCK WAIT', 'ROLLING BACK' или 'COMMITTING'). Блокировка, которая блокирует транзакцию, всегда считается в режиме (чтение по сравнению с записью, совместно использованной по сравнению с монопольным) несовместимая с режимом требуемой блокировки.

    Для табличного определения см. Таблицу 19.5,"INNODB_LOCKS Столбцы".

  • INNODB_LOCK_WAITS

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

    Для табличного определения см. Таблицу 19.6,"INNODB_LOCK_WAITS Столбцы".

14.2.4.3.2.1. Используя Таблицы Информационной схемы Транзакции

Пример 14.3. Идентификация Транзакций Блокирования

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

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

  • User A:

    BEGIN;SELECT a FROM t FOR UPDATE;SELECT SLEEP(100);
  • User B:

    SELECT b FROM t FOR UPDATE;
  • User C:

    SELECT c FROM t FOR UPDATE;

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

SELECT r.trx_id waiting_trx_id,         r.trx_mysql_thread_id waiting_thread,       r.trx_query waiting_query,       b.trx_id blocking_trx_id,        b.trx_mysql_thread_id blocking_thread,       b.trx_query blocking_query   FROM       information_schema.innodb_lock_waits w   INNER JOIN information_schema.innodb_trx b  ON      b.trx_id = w.blocking_trx_id  INNER JOIN information_schema.innodb_trx r  ON  r.trx_id = w.requesting_trx_id;
ожидание trx идентификатор поток ожидания запрос ожидания блокирование trx идентификатор блокирование потока блокирование запроса
A4 6 SELECT b FROM t FOR UPDATE A3 5 SELECT SLEEP(100)
A5 7 SELECT c FROM t FOR UPDATE A3 5 SELECT SLEEP(100)
A5 7 SELECT c FROM t FOR UPDATE A4 6 SELECT b FROM t FOR UPDATE

В вышеупомянутом результате можно идентифицировать пользователей "запросом ожидания" или "блокированием запроса". Поскольку можно видеть:

  • Пользователь Б (trx идентификатор 'A4', поток 6) и Пользователь К (trx идентификатор 'A5', поток 7) оба ожидают Пользователя (trx идентификатор 'A3', поток 5).

  • Пользователь К ожидает Пользователя Б так же как Юзра А.

Можно видеть базовые данные в таблицах INNODB_TRX, INNODB_LOCKS, и INNODB_LOCK_WAITS.

Следующая таблица показывает некоторое демонстрационное содержание INFORMATION_SCHEMA.INNODB_TRX.

идентификатор trx состояние trx trx запускался trx требуемый идентификатор блокировки trx ожидают, запускался вес trx trx mysql распараллеливают идентификатор запрос trx
A3 RUN­NING 2008-01-15 16:44:54 NULL NULL 2 5 SELECT SLEEP(100)
A4 LOCK WAIT 2008-01-15 16:45:09 A4:1:3:2 2008-01-15 16:45:09 2 6 SELECT b FROM t FOR UPDATE
A5 LOCK WAIT 2008-01-15 16:45:14 A5:1:3:2 2008-01-15 16:45:14 2 7 SELECT c FROM t FOR UPDATE

Следующая таблица показывает некоторое демонстрационное содержание INFORMATION_SCHEMA.INNODB_LOCKS.

идентификатор блокировки заблокируйте trx идентификатор режим блокировки тип блокировки таблица блокировки блокировка индексирует пространство блокировки страница блокировки блокировка rec данные блокировки
A3:1:3:2 A3 X RECORD `test`.`t` `PRIMARY` 1 3 2 0x0200
A4:1:3:2 A4 X RECORD `test`.`t` `PRIMARY` 1 3 2 0x0200
A5:1:3:2 A5 X RECORD `test`.`t` `PRIMARY` 1 3 2 0x0200

Следующая таблица показывает некоторое демонстрационное содержание INFORMATION_SCHEMA.INNODB_LOCK_WAITS.

запрос trx идентификатор требуемый идентификатор блокировки блокирование trx идентификатор блокирование идентификатора блокировки
A4 A4:1:3:2 A3 A3:1:3:2
A5 A5:1:3:2 A3 A3:1:3:2
A5 A5:1:3:2 A4 A4:1:3:2

Пример 14.4. Более сложный Пример Данных транзакции в Таблицах Информационной схемы

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

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

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

Следующий INNODB_LOCKS и INNODB_LOCK_WAITS таблицы показывают что:

  • Транзакция 77F (выполнение INSERT) ожидает транзакций 77E, 77D и 77B фиксировать.

  • Транзакция 77E (выполнение ВСТАВКИ), ожидает транзакций 77D и 77B фиксировать.

  • Транзакция 77D (выполнение ВСТАВКИ), ожидает транзакции 77B фиксировать.

  • Транзакция 77B (выполнение ВСТАВКИ), ожидает транзакции 77A фиксировать.

  • Транзакция 77A работает, в настоящий момент выполняясь SELECT.

  • Транзакция E56 (выполнение INSERT) ожидает транзакции E55 фиксировать.

  • Транзакция E55 (выполнение INSERT) ожидает транзакции 19C фиксировать.

  • Транзакция 19C работает, в настоящий момент выполняясь INSERT.

Отметьте, что может быть несогласованность между запросами, показанными в этих двух таблицах INNODB_TRX.TRX_QUERY и PROCESSLIST.INFO. Текущий ID транзакции для потока, и запрос, выполняемый в той транзакции, могут отличаться в этих двух таблицах для любого данного потока. См. Раздел 14.2.4.3.4.3, "Возможная Несогласованность с PROCESSLIST"для объяснения.

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

ID ПОЛЬЗОВАТЕЛЬ УЗЕЛ DB КОМАНДА ВРЕМЯ СОСТОЯНИЕ ИНФОРМАЦИЯ
384 root localhost test Query 10 update insert into t2 values …
257 root localhost test Query 3 update insert into t2 values …
130 root localhost test Query 0 update insert into t2 values …
61 root localhost test Query 1 update insert into t2 values …
8 root localhost test Query 1 update insert into t2 values …
4 root localhost test Query 0 preparing SELECT * FROM processlist
2 root localhost test Sleep 566 NULL

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

идентификатор trx состояние trx trx запускался trx требуемый идентификатор блокировки trx ожидают, запускался вес trx trx mysql распараллеливают идентификатор запрос trx
77F LOCK WAIT 2008-01-15 13:10:16 77F:806 2008-01-15 13:10:16 1 876 insert into t09 (D, B, C) values …
77E LOCK WAIT 2008-01-15 13:10:16 77E:806 2008-01-15 13:10:16 1 875 insert into t09 (D, B, C) values …
77D LOCK WAIT 2008-01-15 13:10:16 77D:806 2008-01-15 13:10:16 1 874 insert into t09 (D, B, C) values …
77B LOCK WAIT 2008-01-15 13:10:16 77B:733​:12:1 2008-01-15 13:10:16 4 873 insert into t09 (D, B, C) values …
77A RUN­NING 2008-01-15 13:10:16 NULL NULL 4 872 select b, c from t09 where …
E56 LOCK WAIT 2008-01-15 13:10:06 E56:743​:6:2 2008-01-15 13:10:06 5 384 insert into t2 values …
E55 LOCK WAIT 2008-01-15 13:10:06 E55:743​:38:2 2008-01-15 13:10:13 965 257 insert into t2 values …
19C RUN­NING 2008-01-15 13:09:10 NULL NULL 2900 130 insert into t2 values …
E15 RUN­NING 2008-01-15 13:08:59 NULL NULL 5395 61 insert into t2 values …
51D RUN­NING 2008-01-15 13:08:47 NULL NULL 9807 8 insert into t2 values …

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

запрос trx идентификатор требуемый идентификатор блокировки блокирование trx идентификатор блокирование идентификатора блокировки
77F 77F:806 77E 77E:806
77F 77F:806 77D 77D:806
77F 77F:806 77B 77B:806
77E 77E:806 77D 77D:806
77E 77E:806 77B 77B:806
77D 77D:806 77B 77B:806
77B 77B:733:12:1 77A 77A:733:12:1
E56 E56:743:6:2 E55 E55:743:6:2
E55 E55:743:38:2 19C 19C:743:38:2

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

идентификатор блокировки заблокируйте trx идентификатор режим блокировки тип блокировки таблица блокировки блокировка индексирует пространство блокировки страница блокировки блокировка rec данные блокировки
77F:806 77F AUTO​_INC TABLE `test`​.`t09` NULL NULL NULL NULL NULL
77E:806 77E AUTO​_INC TABLE `test`​.`t09` NULL NULL NULL NULL NULL
77D:806 77D AUTO​_INC TABLE `test`​.`t09` NULL NULL NULL NULL NULL
77B:806 77B AUTO​_INC TABLE `test`​.`t09` NULL NULL NULL NULL NULL
77B:733​:12:1 77B X RECORD `test`​.`t09` `PRIMARY` 733 12 1 supremum pseudo-record
77A:733​:12:1 77A X RECORD `test`​.`t09` `PRIMARY` 733 12 1 supremum pseudo-record
E56:743​:6:2 E56 S RECORD `test`​.`t2` `PRIMARY` 743 6 2 0, 0
E55:743​:6:2 E55 X RECORD `test`​.`t2` `PRIMARY` 743 6 2 0, 0
E55:743​:38:2 E55 S RECORD `test`​.`t2` `PRIMARY` 743 38 2 1922, 1922
19C:743​:38:2 19C X RECORD `test`​.`t2` `PRIMARY` 743 38 2 1922, 1922

14.2.4.3.3. Таблицы Информационной схемы о Полнотекстовом Поиске

Ряд связанного INFORMATION_SCHEMA таблицы содержат информацию о FULLTEXT поиск индексирует на InnoDB таблицы:

14.2.4.3.4. Специальные Соображения Блокировки для InnoDBINFORMATION_SCHEMA Таблицы

14.2.4.3.4.1. Понимание InnoDB Блокировка

Когда транзакция обновляет строку в таблице, или блокирует это с SELECT FOR UPDATE, InnoDB составляет список, или очередь соединяет ту строку. Точно так же InnoDB поддерживает список, соединяется, таблица для транзакций блокировок на уровне таблицы содержат. Если вторая транзакция хочет обновить строку или заблокировать таблицу, уже заблокированную предшествующей транзакцией в несовместимом режиме, InnoDB добавляет запрос блокировки на строку соответствующей очереди. Для блокировки, которая будет получена транзакцией, все несовместимые запросы блокировки ранее ввели в очередь блокировки для той строки, или таблица должна быть удалена (содержание транзакций или запрос тех блокировок или фиксируют или откатывают).

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

INNODB_LOCKS таблица содержит одну или более строк для каждого 'LOCK WAIT' транзакция, указывая на любые запросы блокировки, которые предотвращают ее продвижение. Эта таблица также содержит одну строку, описывающую, каждый привязывает очередь блокировок, ожидающих для данной строки или таблицы. INNODB_LOCK_WAITS табличные шоу, который блокирует уже сохраненный транзакцией, блокируют блокировки, которые требуют другие транзакции.

14.2.4.3.4.2. Гранулярность INFORMATION_SCHEMA Данные

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

По причинам производительности, и минимизировать шанс вводящих в заблуждение JOINs между INFORMATION_SCHEMA таблицы, InnoDB собирает необходимую транзакцию и информацию о блокировке в промежуточный буфер всякий раз, когда a SELECT на любой из таблиц выпускается. Этот буфер обновляется, только если больше чем 0.1 секунды протекли с прошлого раза был считан буфер. Данные должны были заполниться, эти три таблицы выбирается атомарно и последовательно и сохраняется в этом глобальном внутреннем буфере, формируя момент времени "снимок". Если многократные табличные доступы происходят в течение 0.1 секунд (как они почти наверняка делают, когда MySQL обрабатывает соединение среди этих таблиц), то тот же самый снимок используется, чтобы удовлетворить запрос.

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

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

Поскольку эти таблицы содержат уязвимую информацию (по крайней мере, INNODB_LOCKS.LOCK_DATA и INNODB_TRX.TRX_QUERY), для соображений безопасности, только пользователи с PROCESS полномочию позволяют SELECT от них.

14.2.4.3.4.3. Возможная Несогласованность с PROCESSLIST

Как только описано, в то время как данные транзакции и блокировки являются корректными и непротиворечивыми когда они INFORMATION_SCHEMA таблицы заполняются. Например, запрос в INNODB_TRX является всегда непротиворечивым с остальной частью INNODB_TRX, INNODB_LOCKS и INNODB_LOCK_WAITS когда данные прибывают из того же самого снимка. Однако, базовые данные изменяются настолько быстро, что подобные проблески в другом, так же быстро изменяющихся данных, возможно, не находятся в синхронии. Таким образом следует быть осторожными в сравнении данных в транзакции InnoDB и блокировке таблиц с этим в PROCESSLIST таблица. Данные от PROCESSLIST таблица не прибывает из того же самого снимка как данные о блокировке и транзакциях. Даже если Вы выпускаете сингл SELECT (присоединение INNODB_TRX и PROCESSLIST, например), контент тех таблиц является обычно не непротиворечивым. INNODB_TRX ссылочные строки мая, которые не присутствуют в PROCESSLIST или в настоящий момент выполняющийся SQL-запрос транзакции, показанной в INNODB_TRX.TRX_QUERY может отличаться от того в PROCESSLIST.INFO.