Spec-Zone .ru
спецификации, руководства, описания, API
|
Этот раздел описывает как InnoDB
таблицы, индексирует, и их связанные метаданные
представляются на физическом уровне. Эта информация прежде всего полезна для настройки производительности и
поиска и устранения неисправностей.
MySQL хранит свою информацию словаря данных для таблиц в.frm файлах в каталогах
базы данных. В отличие от других механизмов хранения MySQL, InnoDB
также
кодирует информацию о таблице в ее собственном внутреннем словаре данных в табличной области. Когда MySQL
отбрасывает таблицу или базу данных, он удаляет один или больше .frm
файлы так
же как соответствующие записи в InnoDB
словарь данных. Невозможно переместиться
InnoDB
таблицы между базами данных просто, перемещаясь .frm
файлы.
Каждый 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,
"Используя Первичные ключи".
Специальное предложение отчасти индексирует, 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
.
Все 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
размер страницы не может
использовать файлы данных или файлы журнала от экземпляра, который использует различный размер страницы.
Приложения базы данных часто вставляют новые строки в порядок по возрастанию первичного ключа. В этом случае, из-за расположения кластерного индекса в том же самом порядке как первичный ключ, вставки в таблицу InnoDB не требуют случайных чтений от диска.
С другой стороны, вторичный индексирует, являются обычно групповыми, и вставки во вторичный индексирует,
происходят в относительно произвольном порядке. Таким же образом, удаляет, и обновления могут влиять на
страницы данных, которые не смежны во вторичном, индексирует. Это вызвало бы много случайных дисковых
операций ввода-вывода без специального механизма, используемого в InnoDB
.
Когда индексировать запись вставляется, отметила для удаления, или удалила из группового вторичного
устройства, индексируют, InnoDB
проверки, является ли вторичная индексная
страница в пуле буферов. Если
это так, InnoDB
применяет изменение непосредственно к индексной странице. Если
индексная страница не находится в пуле буферов, InnoDB
записывает изменение в
специальной структуре, известной как буфер вставки. Буфер вставки сохраняется
маленьким так, чтобы он соответствовал полностью в пуле буферов, и изменения могут быть применены очень
быстро. Этот процесс известен как буферизация изменения. (Прежде, это
применялось только к вставкам и было вызвано, вставляют буферизацию. Структуру данных все еще вызывают
буфером вставки.)
Периодически, буфер вставки объединяется во вторичное устройство, индексируют деревья в базе данных. Часто, возможно объединить несколько изменений в ту же самую страницу индексировать дерева, сохраняя дисковые операции ввода-вывода. Это было измерено, что буфер вставки может ускорить вставки в таблицу до 15 раз.
Буферное слияние вставки может продолжать происходить после того, как
транзакция фиксировалась. Фактически, это может продолжать происходить после завершения работы сервера и
перезапуска (см. Раздел 14.2.4.6, "Запускаясь
InnoDB
на Поврежденной Базе данных").
Вставьте буферное слияние, может занять много часов, когда многие вторичные индексируют, должен быть
обновлен, и много строк были вставлены. В это время дисковый ввод-вывод будет увеличен, который может
вызвать существенное замедление на ограниченных диском запросах. Другая существенная фоновая работа
ввода-вывода является потоком
чистки (см. Раздел 14.2.3.11,"InnoDB
Мультиуправление версиями").
Функция, известная как адаптивный хеш, индексирует (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-дерева и Хеша Индексирует".
Физическая структура строки для 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(
байты. (Например, если есть где-нибудь от 9 до 15 столбцов, которые могут быть N
/8)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
во многих случаях позволяет обновлениям столбца быть
сделанными на месте, не вызывая фрагментацию индексной страницы.