Spec-Zone .ru
спецификации, руководства, описания, API
|
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-связанные таблицы Информационной схемы и показывает некоторые примеры их использования.
Две новых пары таблиц Информационной схемы могут дать Вам некоторое понимание, как хорошо сжатие работает повсюду. Одна пара таблиц содержит информацию о числе операций сжатия и количества времени, проведенного, выполняя сжатие. Другая пара таблиц содержит информацию о способе, которым память выделяется для сжатия.
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
".
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. Используя Таблицы Информационной схемы Сжатия
Следующее является демонстрационным выводом от базы данных, которая
содержит сжатые таблицы (см. Раздел 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)
.
Три InnoDB-связанных таблицы Информационной схемы облегчают контролировать транзакции и диагностировать
возможные проблемы блокировки. Эти три таблицы INNODB_TRX
, INNODB_LOCKS
, и INNODB_LOCK_WAITS
.
Содержит информацию о каждой транзакции, в настоящий момент выполняющейся в InnoDB, включая то, ожидает ли транзакция блокировки, когда транзакция, запущенная, и определенный SQL-оператор транзакция, выполняется.
Для табличного определения см. Таблицу
19.4,"INNODB_TRX
Столбцы".
Каждая транзакция в InnoDB, который ожидает другой транзакции, чтобы выпустить блокировку (INNODB_TRX.TRX_STATE='LOCK WAIT'
) блокируется точно одним "запросом блокировки блокирования".
Тот запрос блокировки блокирования для блокировки строки или блокировки таблицы, сохраненной
другой транзакцией в несовместимом режиме. Ожидание или блокированная транзакция не могут
продолжиться, пока другая транзакция не фиксирует или откатывает, таким образом выпуская
требуемую блокировку. Для каждой блокированной транзакции, INNODB_LOCKS
содержит одну строку, которая описывает каждую
блокировку, которую транзакция запросила, и которого это ожидает. INNODB_LOCKS
также содержит одну строку для каждой
блокировки, которая блокирует другую транзакцию, безотносительно состояния транзакции, которая
содержит блокировку ('RUNNING'
, 'LOCK
WAIT'
, 'ROLLING BACK'
или 'COMMITTING'
).
Блокировка, которая блокирует транзакцию, всегда считается в режиме (чтение по сравнению с
записью, совместно использованной по сравнению с монопольным) несовместимая с режимом требуемой
блокировки.
Для табличного определения см. Таблицу
19.5,"INNODB_LOCKS
Столбцы".
Используя эту таблицу, можно сказать, какие транзакции ожидают данной блокировки, или которой
блокировки данная транзакция ожидает. Эта таблица содержит одну или более строк для каждой блокированной транзакции, указывая на блокировку,
которую это запросило и любые блокировки, которые блокируют тот запрос. REQUESTED_LOCK_ID
обращается к блокировке, которую транзакция запрашивает, и BLOCKING_LOCK_ID
обращается к блокировке (сохраненный другой транзакцией), который препятствует тому, чтобы
первая транзакция продолжилась. Для любой данной блокированной транзакции, всех строк в INNODB_LOCK_WAITS
имейте то же самое значение для REQUESTED_LOCK_ID
и различные
значения для BLOCKING_LOCK_ID
.
Для табличного определения см. Таблицу 19.6,"INNODB_LOCK_WAITS
Столбцы".
Пример 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 |
RUNNING |
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
.
Пример 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 |
RUNNING |
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 |
RUNNING |
2008-01-15 13:09:10 |
NULL |
NULL |
2900 |
130 |
insert into t2 values … |
E15 |
RUNNING |
2008-01-15 13:08:59 |
NULL |
NULL |
5395 |
61 |
insert into t2 values … |
51D |
RUNNING |
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 |
Ряд связанного INFORMATION_SCHEMA
таблицы содержат информацию о FULLTEXT
поиск индексирует на InnoDB
таблицы:
Когда транзакция обновляет строку в таблице, или блокирует это с SELECT FOR
UPDATE
, InnoDB составляет список, или очередь соединяет ту строку. Точно так же InnoDB
поддерживает список, соединяется, таблица для транзакций блокировок на уровне таблицы содержат. Если
вторая транзакция хочет обновить строку или заблокировать таблицу, уже заблокированную предшествующей
транзакцией в несовместимом режиме, InnoDB добавляет запрос блокировки на строку соответствующей
очереди. Для блокировки, которая будет получена транзакцией, все несовместимые запросы блокировки ранее
ввели в очередь блокировки для той строки, или таблица должна быть удалена (содержание транзакций или
запрос тех блокировок или фиксируют или откатывают).
У транзакции может быть любое число запросов блокировки на различные строки или таблицы. В любой момент
времени транзакция может запрашивать блокировку, которая сохранена другой транзакцией, когда это
блокируется той другой транзакцией. Транзакция запроса должна ожидать транзакции, которая содержит
блокировку блокирования, чтобы фиксировать или откатывать. Если транзакция не ожидает блокировка, это
находится в 'RUNNING'
состояние. Если транзакция ожидает блокировки, это
находится в 'LOCK WAIT'
состояние.
INNODB_LOCKS
таблица содержит одну или более строк для каждого 'LOCK WAIT'
транзакция, указывая на любые запросы блокировки, которые
предотвращают ее продвижение. Эта таблица также содержит одну строку, описывающую, каждый привязывает
очередь блокировок, ожидающих для данной строки или таблицы. INNODB_LOCK_WAITS
табличные шоу, который блокирует уже сохраненный
транзакцией, блокируют блокировки, которые требуют другие транзакции.
Данные, представленные транзакцией и таблицами блокировки, представляют проблеск в быстро изменяющиеся данные. Это не походит на другой (пользователь) таблицы, где данные изменяются только, когда инициируемые приложением обновления происходят. Базовые данные являются внутренними системными управляемыми данными, и могут измениться очень быстро.
По причинам производительности, и минимизировать шанс вводящих в заблуждение JOIN
s между INFORMATION_SCHEMA
таблицы, InnoDB
собирает необходимую транзакцию и информацию о блокировке в промежуточный буфер всякий раз, когда a
SELECT
на любой из таблиц выпускается. Этот буфер обновляется, только если
больше чем 0.1 секунды протекли с прошлого раза был считан буфер. Данные должны были заполниться, эти
три таблицы выбирается атомарно и последовательно и сохраняется в этом глобальном внутреннем буфере,
формируя момент времени "снимок". Если
многократные табличные доступы происходят в течение 0.1 секунд (как они почти наверняка делают, когда
MySQL обрабатывает соединение среди этих таблиц), то тот же самый снимок используется, чтобы
удовлетворить запрос.
Корректный результат возвращается когда Вы JOIN
любая из этих таблиц вместе
в единственном запросе, потому что данные для этих трех таблиц прибывают из того же самого снимка.
Поскольку буфер не обновляется с каждым запросом ни одной из этих таблиц, если Вы выпускаете отдельные
запросы против этих таблиц в течение одной десятой секунды, результатами является то же самое от запроса
до запроса. С другой стороны два отдельных запроса тех же самых или различных таблиц выпущенная больше
чем одна десятая секунды обособленно могут видеть различные результаты, начиная с данных, прибывших от
различных снимков.
Поскольку InnoDB должен временно остановиться, в то время как данные транзакции и блокировки собираются, слишком частые запросы этих таблиц могут негативно воздействовать на производительность как замечено другими пользователями.
Поскольку эти таблицы содержат уязвимую информацию (по крайней мере, INNODB_LOCKS.LOCK_DATA
и INNODB_TRX.TRX_QUERY
), для соображений безопасности, только пользователи
с PROCESS
полномочию позволяют SELECT
от них.
Как только описано, в то время как данные транзакции и блокировки являются корректными и
непротиворечивыми когда они 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
.