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

14.2.3.13. InnoDB Таблица и Индексирует Структуры

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

14.2.3.13.1. Роль .frm Файл для InnoDBТаблицы

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

14.2.3.13.2. Кластеризируемый и Вторичный Индексирует

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

  • Когда Вы определяете a PRIMARY KEY на Вашей таблице, InnoDB использование это как кластерный индекс. Определите первичный ключ для каждой таблицы, которую Вы составляете. Если нет никакого логического уникального и ненулевого столбца или набора столбцов, добавьте новый столбец автоприращения, значения которого заполнены в автоматически.

  • Если Вы не определяете a PRIMARY KEY для Вашей таблицы MySQL определяет местоположение первого UNIQUE индексируйте, где все ключевые столбцы NOT NULL и InnoDB использование это как кластерный индекс.

  • Если таблица имеет нет PRIMARY KEY или подходящий UNIQUE индексируйте, InnoDB внутренне генерирует скрытый кластерный индекс на синтетическом столбце, содержащем Значения идентификаторов строки. Строки упорядочиваются ID это InnoDB присваивается к строкам в такой таблице. ID строки является 6-байтовым полем, которое увеличивается монотонно, поскольку новые строки вставляются. Таким образом строки, упорядоченные ID строки, находятся физически в порядке вставки.

Как Кластерный индекс Ускоряет Запросы

Доступ к строке через кластерный индекс быстр, потому что индексировать поиск приводит непосредственно к странице со всеми данными строки. Если таблица является большой, архитектура кластерного индекса часто сохраняет дисковую работу ввода-вывода, когда по сравнению с организациями хранения, которые хранят данные строки, используя различную страницу от индексировать записи. (Например, MyISAM использование один файл для строк данных и другой для индексирует записи.)

Как Вторичный Индексирует, Касаются Кластерного индекса

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

Если первичный ключ долог, вторичное устройство индексирует, используют больше пространства, таким образом, выгодно иметь короткий первичный ключ.

Для того, чтобы кодировать направляющие линии, чтобы использовать в своих интересах InnoDB кластеризируемый и вторичный индексирует, см. Раздел 8.3.2, "Используя Первичные ключи" Раздел 8.3, "Оптимизация и Индексирует" Раздел 8.5, "Оптимизируя для InnoDB Таблицы" Раздел 8.3.2, "Используя Первичные ключи".

14.2.3.13.3. FULLTEXT Индексирует

Специальное предложение отчасти индексирует, FULLTEXT индексируйте, помогает InnoDB соглашение с запросами и операциями DML, включающими основанные на тексте столбцы и слова, они содержат. Они индексируют, физически представляются как цельный InnoDB таблицы, на которые действуют ключевые слова SQL такой как FULLTEXT пункт CREATE INDEX оператор, MATCH() ... AGAINST синтаксис в a SELECT оператор, и OPTIMIZE TABLE оператор. Для информации об использовании см. Раздел 12.9, "Полнотекстовые Функции Поиска".

Можно исследовать FULLTEXT индексирует, запрашивая таблицы в INFORMATION_SCHEMA база данных. Можно видеть основной, индексируют информацию для FULLTEXT индексирует, запрашивая INNODB_SYS_INDEXES. Хотя InnoDB FULLTEXT индексирует представляются таблицами, которые обнаруживаются в INNODB_SYS_TABLES запросы, способ контролировать специальные относящиеся к обработке текстов аспекты a FULLTEXT индексируйте должен запросить таблицы INNODB_FT_CONFIG, INNODB_FT_INDEX_TABLE, INNODB_FT_INDEX_CACHE, INNODB_FT_DEFAULT_STOPWORD, INNODB_FT_DELETED, и INNODB_FT_BEING_DELETED.

InnoDB FULLTEXT индексирует обновляются OPTIMIZE TABLE командой, используя специальный режим управляют параметры конфигурации innodb_ft_num_word_optimize и innodb_optimize_fulltext_only.

14.2.3.13.4. Физическая Структура InnoDB Индексировать

Все InnoDB индексирует B-деревья, где индексировать записи сохранены в листовых страницах дерева. Размер значения по умолчанию индексной страницы составляет 16 Кбит. Когда новые записи вставляются, InnoDB попытки оставить 1/16 страницы, свободной для будущих вставок и обновлений индексировать записей.

Если индексируют записи, вставляются в последовательный порядок (возрастание или убывание), получающиеся индексные страницы о полном 15/16. Если записи вставляются в произвольный порядок, страницы от 1/2 до полного 15/16. Если коэффициент заполнения индексной страницы опускается ниже 1/2, InnoDB попытки сократить индексировать дерево, чтобы освободить страницу.

Отметить

Можно определить размер страницы для всех InnoDB табличные области в экземпляре MySQL, устанавливая innodb_page_size параметр конфигурации прежде, чем создать экземпляр. Как только размер страницы для экземпляра MySQL устанавливается, невозможно изменить его. Поддерживаемые размеры составляют 16 Кбит, 8 Кбит, и 4 Кбита, соответствуя значениям опции 16k, 8k, и 4k.

Экземпляр MySQL, используя деталь InnoDB размер страницы не может использовать файлы данных или файлы журнала от экземпляра, который использует различный размер страницы.

14.2.3.13.5. Вставьте Буферизацию

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

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

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

Дисковый ввод-вывод для Сбрасывания Буфера Вставки

Периодически, буфер вставки объединяется во вторичное устройство, индексируют деревья в базе данных. Часто, возможно объединить несколько изменений в ту же самую страницу индексировать дерева, сохраняя дисковые операции ввода-вывода. Это было измерено, что буфер вставки может ускорить вставки в таблицу до 15 раз.

Буферное слияние вставки может продолжать происходить после того, как транзакция фиксировалась. Фактически, это может продолжать происходить после завершения работы сервера и перезапуска (см. Раздел 14.2.4.6, "Запускаясь InnoDB на Поврежденной Базе данных").

Вставьте буферное слияние, может занять много часов, когда многие вторичные индексируют, должен быть обновлен, и много строк были вставлены. В это время дисковый ввод-вывод будет увеличен, который может вызвать существенное замедление на ограниченных диском запросах. Другая существенная фоновая работа ввода-вывода является потоком чистки (см. Раздел 14.2.3.11,"InnoDB Мультиуправление версиями").

14.2.3.13.6. Адаптивный Хеш Индексирует

Функция, известная как адаптивный хеш, индексирует (AHI), позволяет InnoDB выполните больше как база данных в памяти на системах с соответствующими комбинациями рабочей нагрузки и вполне достаточной памяти для пула буферов, не жертвуя никакими транзакционными функциями или надежностью. Эта опция активируется innodb_adaptive_hash_index опция, или выключенный --skip-innodb_adaptive_hash_index при запуске сервера.

Основанный на наблюдаемом образце поисков, MySQL создает хеш, индексируют использование префикса индексировать ключа. Префикс ключа может быть любой длиной, и может случиться так, что только некоторые из значений в B-дереве появляются в хеше, индексируют. Хеш индексирует, создаются по требованию для тех страниц индексирования, к которым часто получают доступ.

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

С некоторыми рабочими нагрузками ускорение от хеша индексирует поиски, значительно перевешивает дополнительную работу, чтобы контролировать, индексируют поиски и поддерживают хеш, индексируют структуру. Иногда, блокировка чтения-записи, которая охраняет доступ к адаптивному хешу, индексирует, может стать источником конкуренции при тяжелых рабочих нагрузках, таких как многократные параллельные соединения. Запросы с LIKE операторы и % подстановочные знаки также имеют тенденцию не извлекать выгоду из AHI. Для рабочих нагрузок, где адаптивный хеш индексируют, не необходим, выключая его уменьшает ненужные издержки производительности. Поскольку трудно предсказать заранее, является ли эта функция подходящей для определенной системы, считайте рабочие сравнительные тесты с этим и включенными и отключенными, используя реалистическую рабочую нагрузку. Архитектурные изменения в MySQL 5.6 и выше делают больше рабочих нагрузок подходящим для того, чтобы запретить адаптивный хеш, индексируют чем в более ранних выпусках, хотя это все еще включается по умолчанию.

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

Можно контролировать, использование адаптивного хеша индексируют и конкуренция для ее использования в SEMAPHORES раздел вывода SHOW ENGINE INNODB STATUS команда. Если Вы видите, что много потоков ожидают на RW-фиксаторе, создаваемом в btr0sea.c, тогда могло бы быть полезно отключить адаптивную индексацию хеша.

Для получения дополнительной информации о показателях производительности хеша индексирует, см. Раздел 8.3.8, "Сравнение B-дерева и Хеша Индексирует".

14.2.3.13.7. Физическая Структура Строки

Физическая структура строки для InnoDB таблица зависит от формата строки, определенного, когда таблица была составлена. По умолчанию, InnoDB использует формат файла Антилопы и COMPACT формат строки. REDUNDANT формат доступен, чтобы сохранить совместимость с более старыми версиями MySQL. Когда Вы включаете innodb_file_per_table установка, можно также использовать более новый формат файла Барракуды с DYNAMIC и COMPRESSED форматы строки, как объяснено в Разделе 5.4.8, "Как InnoDB Столбцы Переменной длины хранилищ" и Раздел 5.4.6, "Работающий с InnoDB Сжатые Таблицы".

Проверять формат строки InnoDB таблица, использовать SHOW TABLE STATUS.

COMPACT формат строки уменьшает пространство памяти строки приблизительно на 20 % за счет увеличивающегося использования ЦП для некоторых операций. Если Ваша рабочая нагрузка является типичной, которая ограничивается уровнями удачного обращения в кэш и дисковой скоростью, COMPACT формат, вероятно, будет быстрее. Если рабочая нагрузка является редким случаем, который ограничивается скоростью ЦП, COMPACT формат мог бы быть медленнее.

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

  • Каждый индексирует запись, содержит 6-байтовый заголовок. Заголовок используется, чтобы соединить последовательные записи, и также в блокировке на уровне строки.

  • Записи в кластерном индексе содержат поля для всех определяемых пользователем столбцов. Кроме того, есть 6-байтовое поле ID транзакции и 7-байтовое поле указателя рулона.

  • Если никакой первичный ключ не был определен для таблицы, каждая запись кластерного индекса также содержит 6-байтовое поле ID строки.

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

  • Запись содержит указатель на каждое поле записи. Если полная длина полей в записи составляет меньше чем 128 байтов, указатель составляет один байт; иначе, два байта. Массив этих указателей вызывают каталогом записи. Область, где эти указатели точку вызывают частью данных записи.

  • Внутренне, InnoDB столбцы символа фиксированной длины хранилищ такой как CHAR(10) в формате фиксированной длины. InnoDB не усекает конечные пробелы от VARCHAR столбцы.

  • SQL NULL оцените резервирует один или два байта в каталоге записи. Помимо этого, SQL NULL оцените резервные нулевые байты в части данных записи если сохраненный в столбце переменной длины. В столбце фиксированной длины это резервирует фиксированную длину столбца в части данных записи. Резервирование фиксированного пространства для NULL значения включают обновлению столбца от NULL к не -NULL значение, которое будет сделано на месте, не вызывая фрагментацию индексной страницы.

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

  • Каждый индексирует запись, содержит 5-байтовый заголовок, которому может предшествовать заголовок переменной длины. Заголовок используется, чтобы соединить последовательные записи, и также в блокировке на уровне строки.

  • Часть переменной длины заголовка записи содержит немного вектора для того, чтобы указать NULL столбцы. Если число столбцов в индексировании, которое может быть NULL N, битовый вектор занимает CEILING(N/8) байты. (Например, если есть где-нибудь от 9 до 15 столбцов, которые могут быть NULL, битовый вектор использует два байта.) Столбцы, которые являются NULL не занимайте место кроме бита в этом векторе. Часть переменной длины заголовка также содержит длины столбцов переменной длины. Каждая длина берет один или два байта, в зависимости от максимальной длины столбца. Если все столбцы в индексировании NOT NULL и имейте фиксированную длину, у заголовка записи нет никакой части переменной длины.

  • Для каждого не -NULL поле переменной длины, заголовок записи содержит длину столбца в одном или двух байтах. Два байта только будут необходимы, если часть столбца будет сохранена внешне в страницах переполнения, или максимальная длина превышает 255 байтов, и фактическая длина превышает 127 байтов. Для внешне сохраненного столбца 2-байтовая длина указывает на длину внутренне сохраненной части плюс 20-байтовый указатель на внешне сохраненную часть. Внутренняя деталь составляет 768 байтов, таким образом, длина 768+20. 20-байтовый указатель хранит истинную длину столбца.

  • Заголовок записи сопровождается по условию содержание не -NULL столбцы.

  • Записи в кластерном индексе содержат поля для всех определяемых пользователем столбцов. Кроме того, есть 6-байтовое поле ID транзакции и 7-байтовое поле указателя рулона.

  • Если никакой первичный ключ не был определен для таблицы, каждая запись кластерного индекса также содержит 6-байтовое поле ID строки.

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

  • Внутренне, InnoDB фиксированная длина хранилищ, фиксированные-width символьные столбцы такой как CHAR(10) в формате фиксированной длины. InnoDB не усекает конечные пробелы от VARCHAR столбцы.

  • Внутренне, InnoDB попытки сохранить UTF-8 CHAR(N) столбцы в N байты, обрезая конечные пробелы. (С REDUNDANT формат строки, такие столбцы занимают 3 × N байты.) Резервирование минимального пространства N во многих случаях позволяет обновлениям столбца быть сделанными на месте, не вызывая фрагментацию индексной страницы.