Spec-Zone .ru
спецификации, руководства, описания, API
|
InnoDB
Мониторы предоставляют информацию о InnoDB
внутреннее состояние. Эта информация полезна для настройки производительности. Каждый Монитор может быть
включен, составляя таблицу со специальным именем, которое вызывает InnoDB
писать
вывод Монитора периодически. Кроме того, выведенный для стандарта InnoDB
Монитор
доступен по требованию через SHOW ENGINE INNODB
STATUS
SQL-оператор.
Есть несколько типов InnoDB
Мониторы:
Стандарт InnoDB
Контрольные дисплеи следующие типы
информации:
Таблица и блокировки записи сохранены каждой активной транзакцией.
Блокировка ожидает транзакции.
Семафор ожидает потоков.
Запросы файлового ввода-вывода на ожидании.
Статистика пула буферов.
Произведите чистку и вставьте буферное действие слияния основного InnoDB
поток.
Для обсуждения InnoDB
режимы блокировки, см. Раздел
14.2.3.2,"InnoDB
Режимы блокировки".
Включать стандарту InnoDB
Монитор для периодического вывода, составьте
названную таблицу innodb_monitor
. Чтобы получить вывод Монитора по
требованию, используйте SHOW ENGINE
INNODB STATUS
SQL-оператор, чтобы выбрать вывод к Вашей клиентской программе. Если Вы
используете mysql
интерактивный клиент, вывод более читаем, если Вы заменяете обычный разделитель оператора точки с
запятой \G
:
mysql> SHOW ENGINE INNODB STATUS\G
InnoDB
Монитор блокировки походит на стандартный
Монитор, но также и предоставляет обширную информацию о блокировке. Чтобы включить этому Монитору для
периодического вывода, составьте названную таблицу innodb_lock_monitor
.
InnoDB
Монитор табличной области печатает список
сегментов файла в совместно используемой табличной области и проверяет структур данных выделения
табличной области. Чтобы включить этому Монитору для периодического вывода, составьте названную таблицу
innodb_tablespace_monitor
.
InnoDB
Табличный Монитор печатает содержание InnoDB
внутренний словарь данных. Чтобы включить этому Монитору для
периодического вывода, составьте названную таблицу innodb_table_monitor
.
С MySQL 5.6.3, innodb_table_monitor
таблица осуждается и
будет удалена в будущем выпуске MySQL. Подобная информация может быть получена из InnoDB
INFORMATION_SCHEMA
таблицы.
См. Раздел 19.30,"INFORMATION_SCHEMA
Таблицы для InnoDB
".
Включать InnoDB
Монитор для периодического вывода, используйте a CREATE TABLE
оператор, чтобы составить таблицу, связанную с Монитором. Например,
чтобы включить стандарту InnoDB
Контролируйте, создайте innodb_monitor
таблица:
CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;
Чтобы остановить Монитор, отбросьте таблицу:
DROP TABLE innodb_monitor;
CREATE
TABLE
синтаксис является только способом передать команду к InnoDB
механизм через синтаксический анализатор SQL MySQL: единственные вещи, что вопрос является именем таблицы innodb_monitor
и это это быть InnoDB
таблица.
Структура таблицы не релевантна вообще для InnoDB
Монитор. Если Вы завершаете
работу сервера, Монитор не перезапускает автоматически, когда Вы перезапускаете сервер. Отбросьте таблицу
Монитора и выпустите новое CREATE TABLE
оператор, чтобы запустить Монитор. (Этот синтаксис может измениться в будущем выпуске.)
PROCESS
полномочие обязано
запускаться или останавливаться InnoDB
Таблицы монитора.
Когда Вы включаете InnoDB
Мониторы для периодического вывода, InnoDB
пишет их вывод в mysqld вывод ошибок стандарта сервера (stderr
).
В этом случае никакой вывод не отправляется клиентам. Когда включено, InnoDB
Мониторы печатают данные о каждых 15 секундах. Вывод сервера обычно направляется к журналу ошибок (см. Раздел 5.2.2,
"Журнал ошибок"). Эти данные полезны в настройке производительности. На Windows запустите
сервер с командной строки в консоли с --console
опция, если Вы хотите направить вывод к окну, а не к журналу ошибок.
InnoDB
отправляет диагностический вывод stderr
или к
файлам, а не к stdout
или буферы памяти фиксированного размера, чтобы избежать
потенциального переполнения буфера. Как побочный эффект, вывод SHOW ENGINE INNODB STATUS
пишется файлу состояния в каталоге данных MySQL
каждые пятнадцать секунд. Имя файла innodb_status.
, где pid
pid
ID
серверного процесса. InnoDB
удаляет файл для нормального завершения работы. Если
аварийные завершения работы произошли, экземпляры этих файлов состояния могут присутствовать и должны быть
удалены вручную. Прежде, чем удалить их, Вы могли бы хотеть исследовать их, чтобы видеть, содержат ли они
полезную информацию о причине аварийных завершений работы. innodb_status.
файл создается только если параметр конфигурации pid
innodb-status-file=1
устанавливается.
InnoDB
Мониторы должны быть включены только, когда Вы фактически хотите видеть
информацию о Мониторе, потому что выведенная генерация действительно приводит к некоторому снижению
работоспособности. Кроме того, если Вы включаете монитору, выведенному, составляя связанную таблицу, Ваш журнал
ошибок может стать довольно большим, если Вы забываете удалять таблицу позже.
Для дополнительной информации о InnoDB
мониторы, см.:
Марк Лейт:
Каждый монитор начинается с заголовка, содержащего метку времени и имя монитора. Например:
================================================090407 12:06:19 INNODB TABLESPACE MONITOR OUTPUT================================================
Заголовок для стандартного Монитора (INNODB MONITOR OUTPUT
) также используется для
Монитора Блокировки потому что последние продукты тот же самый вывод с добавлением дополнительной информации о
блокировке.
Следующие разделы описывают вывод для каждого Монитора.
Монитор Блокировки является тем же самым как стандартным Монитором за исключением того, что это включает
дополнительную информацию о блокировке. Включение любому монитору для периодического вывода, создавая
связанное InnoDB
таблица включает тот же самый поток вывода, но поток включает
дополнительную информацию, если Монитор Блокировки включается. Например, если Вы создаете innodb_monitor
и innodb_lock_monitor
таблицы,
который включает единственный поток вывода. Поток включает дополнительную информацию о блокировке, пока Вы
не отключаете Монитор Блокировки, удаляя innodb_lock_monitor
таблица.
Пример InnoDB
Монитор выводил:
mysql> SHOW ENGINE INNODB
STATUS\G
*************************** 1. row ***************************Status:=====================================030709 13:00:59 INNODB MONITOR OUTPUT=====================================Per second averages calculated from the last 18 seconds----------BACKGROUND THREAD----------srv_master_thread loops: 53 1_second, 44 sleeps, 5 10_second, 7 background, 7 flushsrv_master_thread log flush and writes: 48----------SEMAPHORES----------OS WAIT ARRAY INFO: reservation count 413452, signal count 378357--Thread 32782 has waited at btr0sea.c line 1477 for 0.00 seconds thesemaphore: X-lock on RW-latch at 41a28668 created in file btr0sea.c line 135a writer (thread id 32782) has reserved it in mode wait exclusivenumber of readers 1, waiters flag 1Last time read locked in file btr0sea.c line 731Last time write locked in file btr0sea.c line 1347Mutex spin waits 0, rounds 0, OS waits 0RW-shared spins 2, rounds 60, OS waits 2RW-excl spins 0, rounds 0, OS waits 0Spin rounds per wait: 0.00 mutex, 20.00 RW-shared, 0.00 RW-excl------------------------LATEST FOREIGN KEY ERROR------------------------030709 13:00:59 Transaction:TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195inserting15 lock struct(s), heap size 2496, undo log entries 9MySQL thread id 25, query id 4668733 localhost heikki updateinsert into ibtest11a (D, B, C) values (5, 'khDk' ,'khDk')Foreign key constraint fails for table test/ibtest11a:, CONSTRAINT `0_219242` FOREIGN KEY (`A`, `D`) REFERENCES `ibtest11b` (`A`, `D`) ON DELETE CASCADE ON UPDATE CASCADETrying to add in child table, in index PRIMARY tuple: 0: len 4; hex 80000101; asc ....;; 1: len 4; hex 80000005; asc ....;; 2: len 4; hex 6b68446b; asc khDk;; 3: len 6; hex 0000114e0edc; asc ...N..;; 4: len 7; hex 00000000c3e0a7; asc .......;; 5: len 4; hex 6b68446b; asc khDk;;But in parent table test/ibtest11b, in index PRIMARY,the closest match we can find is record:RECORD: info bits 0 0: len 4; hex 8000015b; asc ...[;; 1: len 4; hex80000005; asc ....;; 2: len 3; hex 6b6864; asc khd;; 3: len 6; hex0000111ef3eb; asc ......;; 4: len 7; hex 800001001e0084; asc .......;; 5:len 3; hex 6b6864; asc khd;;------------------------LATEST DETECTED DEADLOCK------------------------030709 12:59:58*** (1) TRANSACTION:TRANSACTION 0 290252780, ACTIVE 1 sec, process no 3185insertingLOCK WAIT 3 lock struct(s), heap size 320, undo log entries 146MySQL thread id 21, query id 4553379 localhost heikki updateINSERT INTO alex1 VALUES(86, 86, 794,'aA35818','bb','c79166','d4766t','e187358f','g84586','h794',date_format('2001-04-03 12:54:22','%Y-%m-%d%H:%i'),7*** (1) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 indexsymbole trx id 0 290252780 lock mode S waitingRecord lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138;asc aa35818;; 1:*** (2) TRANSACTION:TRANSACTION 0 290251546, ACTIVE 2 sec, process no 3190inserting130 lock struct(s), heap size 11584, undo log entries 437MySQL thread id 23, query id 4554396 localhost heikki updateREPLACE INTO alex1 VALUES(NULL, 32, NULL,'aa3572','','c3572','d6012t','',NULL,'h396', NULL, NULL, 7.31,7.31,7.31,200)*** (2) HOLDS THE LOCK(S):RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 indexsymbole trx id 0 290251546 lock_mode X locks rec but not gapRecord lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138;asc aa35818;; 1:*** (2) WAITING FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 indexsymbole trx id 0 290251546 lock_mode X locks gap before rec insert intentionwaitingRecord lock, heap no 82 RECORD: info bits 0 0: len 7; hex 61613335373230;asc aa35720;; 1:*** WE ROLL BACK TRANSACTION (1)------------TRANSACTIONS------------Trx id counter 0 290328385Purge done for trx's n:o < 0 290315608 undo n:o < 0 17History list length 20Total number of lock structs in row lock hash table 70LIST OF TRANSACTIONS FOR EACH SESSION:---TRANSACTION 0 0, not started, process no 3491MySQL thread id 32, query id 4668737 localhost heikkishow innodb status---TRANSACTION 0 290328384, ACTIVE 0 sec, process no 320538929 inserting1 lock struct(s), heap size 320MySQL thread id 29, query id 4668736 localhost heikki updateinsert into speedc values (1519229,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgjgjlhhgghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjfh---TRANSACTION 0 290328383, ACTIVE 0 sec, process no 318028684 committing1 lock struct(s), heap size 320, undo log entries 1MySQL thread id 19, query id 4668734 localhost heikki updateinsert into speedcm values (1603393,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgjgjlhhgghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjf---TRANSACTION 0 290328327, ACTIVE 0 sec, process no 320036880 starting index readLOCK WAIT 2 lock struct(s), heap size 320MySQL thread id 27, query id 4668644 localhost heikki Searching rows forupdateupdate ibtest11a set B = 'kHdkkkk' where A = 89572------- TRX HAS BEEN WAITING 0 SEC FOR THIS LOCK TO BE GRANTED:RECORD LOCKS space id 0 page no 65556 n bits 232 table test/ibtest11a indexPRIMARY trx id 0 290328327 lock_mode X waitingRecord lock, heap no 1 RECORD: info bits 0 0: len 9; hex 73757072656d756d00;asc supremum.;;---------------------TRANSACTION 0 290328284, ACTIVE 0 sec, process no 319534831 rollback of SQL statementROLLING BACK 14 lock struct(s), heap size 2496, undo log entries 9MySQL thread id 25, query id 4668733 localhost heikki updateinsert into ibtest11a (D, B, C) values (5, 'khDk' ,'khDk')---TRANSACTION 0 290327208, ACTIVE 1 sec, process no 31903278258 lock struct(s), heap size 5504, undo log entries 159MySQL thread id 23, query id 4668732 localhost heikki updateREPLACE INTO alex1 VALUES(86, 46, 538,'aa95666','bb','c95666','d9486t','e200498f','g86814','h538',date_format('2001-04-03 12:54:22','%Y-%m-%d%H:%i'),---TRANSACTION 0 290323325, ACTIVE 3 sec, process no 318530733 inserting4 lock struct(s), heap size 1024, undo log entries 165MySQL thread id 21, query id 4668735 localhost heikki updateINSERT INTO alex1 VALUES(NULL, 49, NULL,'aa42837','','c56319','d1719t','',NULL,'h321', NULL, NULL, 7.31,7.31,7.31,200)--------FILE I/O--------I/O thread 0 state: waiting for i/o request (insert buffer thread)I/O thread 1 state: waiting for i/o request (log thread)I/O thread 2 state: waiting for i/o request (read thread)I/O thread 3 state: waiting for i/o request (write thread)Pending normal aio reads: 0, aio writes: 0, ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0Pending flushes (fsync) log: 0; buffer pool: 0151671 OS file reads, 94747 OS file writes, 8750 OS fsyncs25.44 reads/s, 18494 avg bytes/read, 17.55 writes/s, 2.33 fsyncs/s-------------------------------------INSERT BUFFER AND ADAPTIVE HASH INDEX-------------------------------------Ibuf for space 0: size 1, free list len 19, seg size 21,85004 inserts, 85004 merged recs, 26669 mergesHash table size 207619, used cells 14461, node heap has 16 buffer(s)1877.67 hash searches/s, 5121.10 non-hash searches/s---LOG---Log sequence number 18 1212842764Log flushed up to 18 1212665295Last checkpoint at 18 11358772900 pending log writes, 0 pending chkp writes4341 log i/o's done, 1.22 log i/o's/second----------------------BUFFER POOL AND MEMORY----------------------Total memory allocated 84966343; in additional pool allocated 1402624Buffer pool size 3200Free buffers 110Database pages 3074Modified db pages 2674Pending reads 0Pending writes: LRU 0, flush list 0, single page 0Pages read 171380, created 51968, written 19468828.72 reads/s, 20.72 creates/s, 47.55 writes/sBuffer pool hit rate 999 / 1000--------------ROW OPERATIONS--------------0 queries inside InnoDB, 0 queries in queueMain thread process no. 3004, id 7176, state: purgingNumber of rows inserted 3738558, updated 127415, deleted 33707, read 7557791586.13 inserts/s, 50.89 updates/s, 28.44 deletes/s, 107.88 reads/s----------------------------END OF INNODB MONITOR OUTPUT============================
InnoDB
Вывод монитора ограничивается 1 МБ, когда произведено используя SHOW ENGINE INNODB STATUS
оператор. Этот предел не применяется к выходному,
записанному выводу ошибок сервера.
Некоторые примечания по выходным разделам:
Status
Этот раздел показывает метку времени, имя монитора, и число секунд, что в секунду средние числа основаны на.
Число секунд является прошедшим временем между текущим временем и в прошлый раз InnoDB
Вывод монитора был напечатан.
BACKGROUND THREAD
srv_master_thread
строки показывают работу, сделанную основным фоновым потоком.
SEMAPHORES
Этот раздел сообщает о потоках, ожидающих семафора и статистики по тому, сколько потоков времен нуждалось во
вращении или ожидании на взаимном исключении или семафоре rw-блокировки. Большое количество потоков,
ожидающих семафоров, может быть результатом дискового ввода-вывода, или состязательными проблемами внутри
InnoDB
. Конкуренция может произойти из-за тяжелого параллелизма запросов или
проблем в планировании потоков операционной системы. Установка innodb_thread_concurrency
системная переменная, меньшая чем значение по
умолчанию, могла бы помочь в таких ситуациях. Spin rounds per wait
строка
показывает, что число раундов спин-блокировки на ОС ожидает взаимного исключения.
LATEST FOREIGN KEY ERROR
Этот раздел предоставляет информацию о новой ограничительной ошибке внешнего ключа. Это не присутствует, если никакая такая ошибка не произошла. Содержание включает оператор, который перестал работать так же как информация об ограничении, которое перестало работать и на которые ссылаются и ссылающиеся таблицы.
LATEST DETECTED DEADLOCK
Этот раздел предоставляет информацию о новой мертвой блокировке. Это не присутствует, если никакая мертвая
блокировка не произошла. Шоу содержания, какие транзакции включаются, оператор, который каждый пытался
выполнить, блокировки, которые они имеют и нуждаются, и который транзакция InnoDB
решенный, чтобы откатывать, чтобы найти выход из тупика. Режимы
блокировки, о которых сообщают в этом разделе, объясняются в Разделе
14.2.3.2,"InnoDB
Режимы блокировки".
TRANSACTIONS
Если эта блокировка отчетов раздела ожидает, у Ваших приложений могла бы быть конкуренция за блокировку. Вывод может также помочь проследить причины мертвых блокировок транзакции.
FILE I/O
Этот раздел предоставляет информацию о потоках это InnoDB
использование, чтобы
выполнить различные типы ввода-вывода. Первые немногие из них выделяются общему InnoDB
обработка. Содержание также выводит на экран информацию для операций
ввода-вывода на ожидании и статистику для производительности ввода-вывода.
Числом этих потоков управляют innodb_read_io_threads
и innodb_write_io_threads
параметры. См. Раздел
14.2.6,"InnoDB
Опции запуска и Системные Переменные".
INSERT BUFFER AND ADAPTIVE HASH INDEX
Этот раздел показывает состояние InnoDB
вставьте буферный и адаптивный хеш,
индексируют. (См. Раздел 14.2.3.13.5, "Вставьте Буферизация",
и Раздел 14.2.3.13.6, "Адаптивный Хеш
Индексирует".) Содержание включает число операций, выполняемых для каждого, плюс статистика для
хеша индексируют производительность.
LOG
Этот раздел выводит на экран информацию о InnoDB
журнал. Содержание включает
текущий порядковый номер журнала, как далеко журнал был сброшен к диску, и позиции в который InnoDB
последний взял контрольную точку. (См. Раздел
5.3.3,"InnoDB
Контрольные точки".) Раздел также выводит на
экран информацию о записях на ожидании и статистике производительности записи.
BUFFER POOL AND MEMORY
Этот раздел дает Вам статистику по чтению страниц и записанный. Можно вычислить от этих чисел, сколько операций ввода-вывода файла данных Ваши запросы в настоящий момент делают.
Для дополнительной информации о работе пула буферов см. Раздел
8.9.1," InnoDB
Пул буферов".
ROW OPERATIONS
Этот раздел показывает то, что основной поток делает, включая число и уровень производительности для каждого типа работы строки.
В MySQL 5.7, выведенном от стандартного Монитора, включает дополнительные разделы по сравнению с выводом для
предыдущих версий. Для получения дополнительной информации см.
InnoDB
Монитор табличной области печатает информацию о сегментах файла в
совместно используемой табличной области и проверяет структур данных выделения табличной области. Если Вы
используете отдельные табличные области, включая innodb_file_per_table
, Монитор Табличной области не описывает те
табличные области.
Пример InnoDB
Монитор табличной области выводил:
================================================090408 21:28:09 INNODB TABLESPACE MONITOR OUTPUT================================================FILE SPACE INFO: id 0size 13440, free limit 3136, free extents 28not full frag extents 2: used pages 78, full frag extents 3first seg id not used 0 23845SEGMENT id 0 1 space 0; page 2; res 96 used 46; full ext 0fragm pages 32; free extents 0; not full extents 1: pages 14SEGMENT id 0 2 space 0; page 2; res 1 used 1; full ext 0fragm pages 1; free extents 0; not full extents 0: pages 0SEGMENT id 0 3 space 0; page 2; res 1 used 1; full ext 0fragm pages 1; free extents 0; not full extents 0: pages 0...SEGMENT id 0 15 space 0; page 2; res 160 used 160; full ext 2fragm pages 32; free extents 0; not full extents 0: pages 0SEGMENT id 0 488 space 0; page 2; res 1 used 1; full ext 0fragm pages 1; free extents 0; not full extents 0: pages 0SEGMENT id 0 17 space 0; page 2; res 1 used 1; full ext 0fragm pages 1; free extents 0; not full extents 0: pages 0...SEGMENT id 0 171 space 0; page 2; res 592 used 481; full ext 7fragm pages 16; free extents 0; not full extents 2: pages 17SEGMENT id 0 172 space 0; page 2; res 1 used 1; full ext 0fragm pages 1; free extents 0; not full extents 0: pages 0SEGMENT id 0 173 space 0; page 2; res 96 used 44; full ext 0fragm pages 32; free extents 0; not full extents 1: pages 12...SEGMENT id 0 601 space 0; page 2; res 1 used 1; full ext 0fragm pages 1; free extents 0; not full extents 0: pages 0NUMBER of file segments: 73Validating tablespaceValidation ok---------------------------------------END OF INNODB TABLESPACE MONITOR OUTPUT=======================================
Вывод Монитора Табличной области включает информацию о совместно используемой табличной области в целом, сопровождаемый списком, содержащим отказ для каждого сегмента в пределах табличной области.
В этом примере, используя размер страницы значения по умолчанию, табличная область состоит из страниц базы данных, которые составляют 16 Кбит каждый. Страницы группируются в степени размера 1 МБ (64 последовательных страницы).
У начальной части вывода, который выводит на экран полную информацию о табличной области, есть этот формат:
FILE SPACE INFO: id 0size 13440, free limit 3136, free extents 28not full frag extents 2: used pages 78, full frag extents 3first seg id not used 0 23845
Полная информация о табличной области включает эти значения:
id
: ID табличной области. Значение 0 обращается к
совместно используемой табличной области.
size
: Текущий размер табличной области в страницах.
free limit
: Минимальный номер страницы, для
которого не был инициализирован свободный список. Страницы в или выше этого предела свободны.
free extents
: Число свободных степеней.
not full frag extents
, used
pages
: Число степеней фрагмента, которые не абсолютно заполнены, и число страниц в тех
степенях, которые были выделены.
full frag extents
: Число абсолютно полных степеней
фрагмента.
first seg id not used
: Первый неиспользованный ID
сегмента.
У отдельной информации о сегменте есть этот формат:
SEGMENT id 0 15 space 0; page 2; res 160 used 160; full ext 2fragm pages 32; free extents 0; not full extents 0: pages 0
Информация о сегменте включает эти значения:
id
: ID сегмента.
space
, page
: Число табличной области и страница в
пределах табличной области, где сегмент "inode" располагается. Число табличной области 0 указывает на
совместно используемую табличную область. InnoDB
использование inodes, чтобы
отследить сегменты в табличной области. Другие поля, выведенные на экран для сегмента (id
, res
, и т.д), получаются из информации в
inode.
res
: Число страниц, выделенных (зарезервированный) для сегмента.
used
: Число выделенных страниц в использовании сегментом.
full ext
: Число степеней, выделенных для сегмента, которые полностью
используются.
fragm pages
: Число начальных страниц, которые были выделены сегменту.
free extents
: Число степеней, выделенных для сегмента, которые абсолютно
неиспользованы.
not full extents
: Число степеней, выделенных для сегмента, которые частично
используются.
pages
: Число страниц используется в пределах не-полных-объемов.
Когда сегмент растет, он запускается как единственная страница, и InnoDB
выделяет первые страницы для этого по одному, до 32 страниц (это fragm pages
значение). После этого, InnoDB
выделяет полные степени. InnoDB
может составить в целом 4 степени за один раз к большому сегменту, чтобы гарантировать хороший sequentiality
данных.
Для сегмента в качестве примера, показанного ранее, у этого есть 32 страницы фрагмента, плюс 2 полных объема (64 страницы каждый), для в общей сложности 160 страниц, используемых из выделенных 160 страниц. У следующего сегмента есть 32 страницы фрагмента и один частично полный объем, используя 14 страниц для в общей сложности 46 страниц, используемых из выделенных 96 страниц:
SEGMENT id 0 1 space 0; page 2; res 96 used 46; full ext 0fragm pages 32; free extents 0; not full extents 1: pages 14
Это возможно для сегмента, которому выделили степени этому, чтобы иметь a fragm
pages
оцените меньше чем 32, если некоторые из отдельных страниц были освобождены последующие за
выделением экстента.
InnoDB
Табличный Монитор печатает содержание InnoDB
внутренний словарь данных.
Вывод содержит один раздел на таблицу. SYS_FOREIGN
и SYS_FOREIGN_COLS
разделы для внутренних таблиц словаря данных, которые поддерживают информацию о внешних ключах. Есть также
разделы для Табличной таблицы Монитора и каждого создаваемого пользователем InnoDB
таблица. Предположите, что следующие две таблицы были составлены в
test
база данных:
CREATE TABLE parent( par_id INT NOT NULL, fname CHAR(20), lname CHAR(20), PRIMARY KEY (par_id), UNIQUE INDEX (lname, fname)) ENGINE = INNODB;CREATE TABLE child( par_id INT NOT NULL, child_id INT NOT NULL, name VARCHAR(40), birth DATE, weight DECIMAL(10,2), misc_info VARCHAR(255), last_update TIMESTAMP, PRIMARY KEY (par_id, child_id), INDEX (name), FOREIGN KEY (par_id) REFERENCES parent (par_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE = INNODB;
Затем Табличный вывод Монитора будет выглядеть примерно так (переформатированный немного):
===========================================090420 12:09:32 INNODB TABLE MONITOR OUTPUT===========================================--------------------------------------TABLE: name SYS_FOREIGN, id 0 11, columns 7, indexes 3, appr.rows 1 COLUMNS: ID: DATA_VARCHAR DATA_ENGLISH len 0; FOR_NAME: DATA_VARCHAR DATA_ENGLISH len 0; REF_NAME: DATA_VARCHAR DATA_ENGLISH len 0; N_COLS: DATA_INT len 4; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; INDEX: name ID_IND, id 0 11, fields 1/6, uniq 1, type 3 root page 46, appr.key vals 1, leaf pages 1, size pages 1 FIELDS: ID DB_TRX_ID DB_ROLL_PTR FOR_NAME REF_NAME N_COLS INDEX: name FOR_IND, id 0 12, fields 1/2, uniq 2, type 0 root page 47, appr.key vals 1, leaf pages 1, size pages 1 FIELDS: FOR_NAME ID INDEX: name REF_IND, id 0 13, fields 1/2, uniq 2, type 0 root page 48, appr.key vals 1, leaf pages 1, size pages 1 FIELDS: REF_NAME ID--------------------------------------TABLE: name SYS_FOREIGN_COLS, id 0 12, columns 7, indexes 1, appr.rows 1 COLUMNS: ID: DATA_VARCHAR DATA_ENGLISH len 0; POS: DATA_INT len 4; FOR_COL_NAME: DATA_VARCHAR DATA_ENGLISH len 0; REF_COL_NAME: DATA_VARCHAR DATA_ENGLISH len 0; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; INDEX: name ID_IND, id 0 14, fields 2/6, uniq 2, type 3 root page 49, appr.key vals 1, leaf pages 1, size pages 1 FIELDS: ID POS DB_TRX_ID DB_ROLL_PTR FOR_COL_NAME REF_COL_NAME--------------------------------------TABLE: name test/child, id 0 14, columns 10, indexes 2, appr.rows 201 COLUMNS: par_id: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 4; child_id: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 4; name: DATA_VARCHAR prtype 524303 len 40; birth: DATA_INT DATA_BINARY_TYPE len 3; weight: DATA_FIXBINARY DATA_BINARY_TYPE len 5; misc_info: DATA_VARCHAR prtype 524303 len 255; last_update: DATA_INT DATA_UNSIGNED DATA_BINARY_TYPE DATA_NOT_NULL len 4; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; INDEX: name PRIMARY, id 0 17, fields 2/9, uniq 2, type 3 root page 52, appr.key vals 201, leaf pages 5, size pages 6 FIELDS: par_id child_id DB_TRX_ID DB_ROLL_PTR name birth weight misc_info last_update INDEX: name name, id 0 18, fields 1/3, uniq 3, type 0 root page 53, appr.key vals 210, leaf pages 1, size pages 1 FIELDS: name par_id child_id FOREIGN KEY CONSTRAINT test/child_ibfk_1: test/child ( par_id ) REFERENCES test/parent ( par_id )--------------------------------------TABLE: name test/innodb_table_monitor, id 0 15, columns 4, indexes 1, appr.rows 0 COLUMNS: i: DATA_INT DATA_BINARY_TYPE len 4; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; INDEX: name GEN_CLUST_INDEX, id 0 19, fields 0/4, uniq 1, type 1 root page 193, appr.key vals 0, leaf pages 1, size pages 1 FIELDS: DB_ROW_ID DB_TRX_ID DB_ROLL_PTR i--------------------------------------TABLE: name test/parent, id 0 13, columns 6, indexes 2, appr.rows 299 COLUMNS: par_id: DATA_INT DATA_BINARY_TYPE DATA_NOT_NULL len 4; fname: DATA_CHAR prtype 524542 len 20; lname: DATA_CHAR prtype 524542 len 20; DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; INDEX: name PRIMARY, id 0 15, fields 1/5, uniq 1, type 3 root page 50, appr.key vals 299, leaf pages 2, size pages 3 FIELDS: par_id DB_TRX_ID DB_ROLL_PTR fname lname INDEX: name lname, id 0 16, fields 2/3, uniq 2, type 2 root page 51, appr.key vals 300, leaf pages 1, size pages 1 FIELDS: lname fname par_id FOREIGN KEY CONSTRAINT test/child_ibfk_1: test/child ( par_id ) REFERENCES test/parent ( par_id )-----------------------------------END OF INNODB TABLE MONITOR OUTPUT==================================
Для каждой таблицы Табличный вывод Монитора содержит раздел, который выводит на экран общую информацию о таблице и определенную информацию о ее столбцах, индексирует, и внешние ключи.
Общая информация для каждой таблицы включает имя таблицы (в
формат за исключением внутренних таблиц), его ID, число столбцов и индексирует, и приблизительное количество
строки. db_name
/tbl_name
COLUMNS
часть табличного раздела перечисляет каждый столбец в таблице.
Информация для каждого столбца указывает на свое имя и характеристики типа данных. Некоторые внутренние
столбцы добавляются InnoDB
, такой как DB_ROW_ID
(ID строки), DB_TRX_ID
(ID транзакции), и DB_ROLL_PTR
(указатель на данные отката/отмены).
DATA_
:
Эти символы указывают на тип данных. Там может быть многократным xxx
DATA_
символы для данного столбца. xxx
prtype
: "Точный"
тип столбца. Это поле включает информацию, такую как тип данных столбца, код набора символов, nullability, signedness, и является ли это двоичной строкой. Это поле описывается в innobase/include/data0type.h
исходный файл.
len
: Длина столбца в байтах.
Каждый INDEX
часть табличного раздела обеспечивает имя, и характеристики одной
таблицы индексируют:
name
: Имя индекса. Если имя PRIMARY
,
индексирование является первичным ключом. Если имя GEN_CLUST_INDEX
,
индексирование является кластерным индексом, который создается автоматически, если табличное
определение не включает первичный ключ или не -NULL
уникальный индекс.
См. Раздел 14.2.3.13.2, "Кластеризируемый
и Вторичный Индексирует".
id
: Индексировать ID.
fields
: Число полей в индексировании, как значение
в
формат:m
/n
m
число определяемых
пользователем столбцов; то есть, число столбцов Вы видели бы в индексировать определении
в a CREATE TABLE
оператор.
n
общее количество,
индексируют столбцы, включая добавленных внутренне. Для кластерного индекса общее
количество включает другие столбцы в табличное определение плюс любые столбцы,
добавленные внутренне. Поскольку вторичное устройство индексирует, общее количество
включает столбцы от первичного ключа, которые не являются частью вторичного устройства,
индексируют.
uniq
: Число ведущих полей, которых является
достаточно, чтобы определить, индексирует значения уникально.
type
: Индексировать тип. Это - немного поля.
Например, 1 указывает, что кластерный индекс и 2 указывает на уникальный индекс, таким образом, у
кластерного индекса (который всегда содержит уникальные значения), будет a type
значение 3. Индексирование с a type
значение 0 ни не кластеризируется,
ни не уникально. Флаговые значения определяются в innobase/include/dict0mem.h
исходный файл.
root page
: Индексировать корневой номер страницы.
appr. key vals
: Приблизительные индексируют
количество элементов.
leaf pages
: Приблизительное количество листовых
страниц в индексировании.
size pages
: Приблизительное общее количество
страниц в индексировании.
FIELDS
: Имена полей в индексировании. Для
кластерного индекса, который был сгенерирован автоматически, cписок полей начинается с внутреннего
DB_ROW_ID
(ID строки) поле. DB_TRX_ID
и
DB_ROLL_PTR
всегда добавляются внутренне к кластерному индексу, после
полей, которые включают первичный ключ. Поскольку вторичное устройство индексирует, заключительные
поля - те от первичного ключа, которые не являются частью вторичного устройства, индексируют.
Конец табличного раздела перечисляет FOREIGN KEY
определения, которые
применяются к таблице. Эта информация появляется, является ли таблица ссылкой или таблицей, на которую
ссылаются.