Структуры таблиц и индексов
В MySQL информация словаря данных таблиц хранится в файлах '.frm', расположенных в каталогах баз данных. Но для каждой таблицы InnoDB имеются также свои записи во внутренних словарях данных InnoDB в табличной области. Когда MySQL удаляет таблицу или базу данных, необходимо удалить как файлы '.frm', так и соответствующие записи в словаре данных InnoDB. Именно поэтому нельзя перемещать таблицы InnoDB между базами данных путем простого перемещения файлов '.frm'. По этой же причине DROP DATABASE не работал для таблиц InnoDB в MySQL версий <= 3.23.43.
Для всех таблиц InnoDB есть специальный индекс, в котором хранятся данные строк - он называется кластеризованным индексом. Если в таблице определить PRIMARY KEY, то индекс первичного ключа будет кластеризированным индексом.
Если первичный ключ для таблицы не определен, то InnoDB самостоятельно создаст кластеризированный индекс; строки в этом индексе будут упорядочены по идентификатору строки, который InnoDB назначил строкам этой таблицы. Идентификатор строки представляет собой 6-байтовое поле, значение которого постоянно увеличивается при вставке новых строк. Таким образом, сортировка по идентификатору строки фактически представляет собой сортировку по последовательности вставки.
Доступ к строке через кластеризированный индекс осуществляется достаточно быстро, поскольку данные строки находятся на той же странице, к которой приводит поиск по индексу. Во многих базах данных информация и индексная запись традиционно хранятся на разных страницах. При больших размерах таблицы архитектура кластеризированных индексов часто позволяет сократить количество дисковых операций ввода/вывода по сравнению с традиционными решениями.
Записи в некластеризированных индексах (мы называем их также вторичными индексами), в InnoDB содержат значение первичного ключа для строки. InnoDB использует этот значение первичного ключа для поиска строки в кластеризированном индексе. Следует учитывать, что если первичный ключ достаточно велик, вторичные индексы будут занимать больше места.
Физическая структура индекса
Все индексы в InnoDB представляют собой B-деревья, в которых записи индексов хранятся в страницах ответвления дерева. По умолчанию размер индексной страницы составляет 16 Кб. При вставке новых записей InnoDB старается оставить 1 / 16 страницы свободной - для будущих вставок и обновлений индексных записей.
Если записи индекса вставлены в последовательном порядке (в порядке возрастания или убывания), то получившиеся индексные страницы будут заполнены примерно на 15/16. Для записей, которые вставляются в случайном порядке, эти значения составят от 1/2 до 15/16. Если коэффициент заполнения индексной страницы уменьшится и станет ниже 1/2, InnoDB попытается объединить записи индексного дерева, чтобы освободить страницу.
Буферизация вставок
Нередко в программах для работы с базами данных первичный ключ является уникальным идентификатором и новые строки вставляются в порядке возрастания первичного ключа. Таким образом, вставки в кластеризированный индекс не требуют проведения случайных считываний с диска.
Что же касается вторичных индексов, то они, напротив, обычно не являются уникальными, так что вставки во вторичные индексы производятся в относительно случайном порядке. Это приводит к выполнению большого количества случайных дисковых операций ввода/вывода диска, если не используется специальный механизм, применяемый в InnoDB.
Если требуется вставить запись индекса во вторичный индекс, который не является уникальным, InnoDB проверяет, находится ли страница вторичного индекса в буферном пуле. Если она там есть, InnoDB произведет вставку непосредственно в страницу индекса. Но если страница индекса не найдена в буферном пуле, InnoDB вставляет запись в специальную структуру буфера вставок. Буфер вставок настолько мал, что полностью помещается в буферный пул, и вставки в него могут производиться очень быстро.
Буфер вставок периодически объединяется с деревьями вторичных индексов в базе данных. Часто, объединив несколько вставок на одной странице индексного дерева, можно за счет этого сократить количество операций ввода/вывода диска. Использование буфера вставки может ускорить вставку в таблицу в 15 раз.
Адаптивный хешированный индекс
Если база данных почти полностью помещается в основной памяти, то самым быстрым способом выполнения запросов по этой базе данных является использование хешированных индексов. В InnoDB существует автоматический механизм, который отслеживает поиск по индексу, осуществляемый по индексам, определенным для таблицы, и если InnoDB посчитает, что запросы выиграют от создания хешированного индекса, такой индекс будет создан автоматически.
Но следует учитывать, что хешированный индекс всегда создается на основе существующего индекса B-дерева таблицы. InnoDB может создать хешированный индекс на префиксах любой длины ключа, определенного для B-дерева, в зависимости от того, по какой схеме поиска InnoDB производит обзор индекса the B-дерева. Хешированный индекс может быть частичным: не обязательно кэшировать в буферном пуле весь индекс B-дерева. InnoDB будет создавать хешированные индексы по запросу для тех страниц индекса, к которым часто производится доступ.
Хотя механизм адаптивного хешированного индекса InnoDB приспосабливается к большому количеству основной памяти, он больше подходит для архитектуры баз данных основной памяти.
Физическая структура записи
У всех записей индекса в InnoDB есть заголовок, состоящий из 6 байтов. Заголовок используется для связывания вместе последовательных записей, а также при блокировке на уровне строк.
Записи в кластеризированном индексе содержат поля для всех столбцов, определенных пользователем. Кроме того, имеется 6-байтовое поле для идентификатора транзакции и 7-байтовое поле для указателя строки.
Если пользователь не определил для таблицы первичный ключ, то в каждой записи кластеризированного индекса также содержится 6-байтовое поле идентификатора строки.
Все записи вторичного индекса содержат также все поля, определенные для ключа кластеризированного индекса.
Запись также содержит указатель на каждое поле записи. Если общая длина полей в записи меньше 128 байтов, то размер указателя будет 1 байт, в противном случае - 2 байта.
Как работают автоинкрементные столбцы в InnoDB
Когда пользователь после запуска базы данных осуществляет первую вставку в таблицу T, где определен автоинкрементный столбец, и пользователь не предоставляет конкретного значения для этого столбца, InnoDB выполняет SELECT MAX(auto-inc-column) FROM T, затем присваивает это значение, увеличенное на единицу, столбцу, и автоматически увеличивает счетчик таблицы. Эту последовательность действий мы называем инициализацией счетчика автоматического увеличения для таблицы T.
Ту же последовательность действий InnoDB выполняет и для инициализации автоинкрементного счетчика вновь созданной таблицы.
Обратите внимание: если пользователь указывает при вставке значение автоинкрементного столбца 0, то InnoDB обрабатывает строку так, как будто значение не было указано.
Если после инициализации автоматического увеличения счетчика пользователь вставляет строку, в которой он явно указывает значение столбца, и это значение превышает текущее значение счетчика, то счетчик устанавливается в указанное значение столбца. Если пользователь явно не указывает значение, то InnoDB увеличивает счетчик на единицу и присваивает столбцу это новое значение.
При присвоении значений из счетчика механизм автоматического увеличения обходит блокировку и управление транзакциями. Вследствие этого могут возникнуть пропуски в последовательности чисел в случае, если производится откат транзакций, которые получили номера из счетчика.
Для случаев, когда пользователь присваивает столбцу отрицательное значение или если значение превысит максимальное целое число, которое может храниться в переменной целочисленного типа, поведение механизма механического увеличения не определено.
1 2 3 4 5 6 7 8 9 10 11
8 8 8
| |
*
Обратная связь