5.5.6. Детали реализации Онлайнового DDL

Каждый ALTER TABLE работа для InnoDB таблицей управляют несколько аспектов:

Есть ли какое-либо изменение к физическому представлению таблицы, или ли это просто изменение к метаданным, которые могут быть сделаны, не касаясь таблицы непосредственно.
Остается ли объем данных в таблице то же самое, увеличения, или уменьшения.
Включает ли изменение в табличных данных кластерный индекс, вторичный индексирует, или оба.
Есть ли какие-либо отношения внешнего ключа между измененной таблицей и некоторой другой таблицей. Механика отличается в зависимости от ли foreign_key_checks параметр конфигурации включается или отключается.
Делится ли таблица. Разделение пунктов ALTER TABLE превращаются в низкоуровневые операции, включающие одну или более таблиц, и те операции следуют за регулярными правилами для онлайнового DDL.
Должны ли табличные данные быть скопированы, может ли таблица быть реорганизована "оперативная", или комбинация обоих.
Содержит ли таблица какие-либо столбцы автоприращения.
Какой степень блокировки требуется, или природой базовых операций базы данных, или a LOCK пункт, который Вы определяете в ALTER TABLE оператор.

Этот раздел объясняет, как эти факторы влияют на различные виды ALTER TABLE операции на InnoDB таблицы.

Состояния ошибки для Онлайнового DDL

Вот основные причины, почему онлайновая работа DDL могла перестать работать:

Если a LOCK пункт определяет низкую степень блокировки (SHARED или NONE) это не является совместимым с определенным типом работы DDL.
Если тайм-аут происходит, ожидая, чтобы получить монопольную блокировку на таблице, которая необходима кратко во время начальных и заключительных фаз работы DDL.
Если tmpdir файловая система исчерпывает дисковое пространство, в то время как MySQL пишет временные файлы вида на диске во время создания индекса.
Если ALTER TABLE занимает много времени, и параллельный DML изменяет таблицу так, что размер временного онлайнового длинного превышает значение innodb_online_alter_log_max_size параметр конфигурации. Это условие вызывает a DB_ONLINE_LOG_TOO_BIG ошибка.
Если параллельный DML производит изменения в таблице, которые позволяются с исходным табличным определением, но не с новым. Работа только перестала работать в самом конце, когда MySQL пытается применить все изменения от параллельных операторов DML. Например, Вы могли бы вставить двойные значения в столбец, в то время как уникальный индекс создается, или Вы могли бы вставить NULL значения в столбец, создавая первичный ключ индексируют на том столбце. Изменения, произведенные параллельным DML, имеют приоритет, и ALTER TABLE работа эффективно откатывается.

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

У InnoDB есть два типа, индексирует: кластерный индекс, представляющий все данные в таблице, и дополнительное вторичное устройство, индексирует, чтобы ускорить запросы. Так как кластерный индекс содержит значения данных в своих узлах B-дерева, добавляя или отбрасывание кластерного индекса действительно включают копирование данных, и создание новой копии таблицы. Вторичное устройство индексирует, однако, содержит только индексировать ключ и значение первичного ключа. Этот тип индексирует, может быть создан или отброшен, не копируя данные в кластерном индексе. Поскольку каждое вторичное устройство индексирует, содержит копии значений первичного ключа (имел обыкновение получать доступ к кластерному индексу при необходимости), когда Вы изменяете определение первичного ключа, все вторичное устройство индексирует, воссоздаются также.

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

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

Первичный ключ и Вторичный Ключ Индексируют

Исторически, сервер MySQL и InnoDB каждый сохранили их собственные метаданные о таблице и индексируют структуры. Сервер MySQL хранит эту информацию в.frm файлах, которые не защищаются транзакционным механизмом, в то время как InnoDB имеет его собственный словарь данных как часть системной табличной области. Если бы работа DDL была прервана катастрофическим отказом или другим неожиданным событием отчасти через, то метаданные можно было оставить непоследовательными между этими двумя расположениями, вызывая проблемы, такие как ошибки запуска или неспособность получить доступ к таблице, которая изменялась. Теперь, когда InnoDB механизм хранения значения по умолчанию, решение таких проблем является высоким приоритетом. Эти улучшения к операциям DDL уменьшают удобный момент для таких проблем, чтобы произойти.