14.2.4.3. InnoDB INFORMATION_SCHEMA таблицы

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

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

Для табличного определения см. Таблицу 20.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 был запущен.

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

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

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

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

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

По причинам производительности, и минимизировать шанс вводящих в заблуждение JOINs между 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.