5.5.2. Производительность и Соображения Параллелизма для Онлайнового DDL

Онлайновый DDL улучшает несколько аспектов работы MySQL, таких как производительность, параллелизм, доступность, и масштабируемость:

Поскольку запросы и операции DML на таблице могут продолжиться, в то время как DDL происходит, приложения, которые получают доступ к таблице, являются более быстро реагирующими. Уменьшенная блокировка и ожидание других ресурсов все всюду по серверу MySQL приводят к большей масштабируемости, даже для операций, не включающих измененную таблицу.
Для оперативных операций, избегая дискового ввода-вывода и циклов ЦП, чтобы восстановить таблицу, Вы минимизируете полную загрузку на базе данных и поддерживаете хорошую производительность и высокую пропускную способность во время работы DDL.
Для оперативных операций, потому что меньше данных читается в пул буферов, чем если бы все данные были скопированы, Вы избегаете производить чистку данных, к которым часто получают доступ, из памяти, которые прежде могли вызвать временное падение производительности после работы DDL.

Блокировка Опций для Онлайнового DDL

В то время как таблица InnoDB изменяется работой DDL, таблица может или не может быть заблокирована, в зависимости от внутренних работ той работы и LOCK пункт ALTER TABLE оператор. По умолчанию MySQL использует так небольшую блокировку насколько возможно во время работы DDL; Вы определяете пункт или чтобы сделать блокировку более рестриктивной, чем это обычно было бы (таким образом ограничение параллельного DML, или DML и запросов), или гарантировать, что некоторая ожидаемая степень блокировки позволяется для работы. Если LOCK пункт определяет уровень блокировки, которая не доступна для того определенного вида работы DDL, такой как LOCK=SHARED или LOCK=NONE создавая или отбрасывая первичный ключ, пункт работает как утверждение, заставляя оператор перестать работать с ошибкой. Следующий список показывает различные возможности для LOCK пункт, от самого разрешающего до самого рестриктивного:

Для операций DDL с LOCK=NONE, оба запроса и параллельный DML позволяются. Этот пункт делает ALTER TABLE перестаньте работать, если вид работы DDL не может быть выполнен с требуемым типом блокировки, так что определите LOCK=NONE если хранение полностью доступной таблицы жизненно важно, и нормально отменять DDL, если это не возможно. Например, Вы могли бы использовать этот пункт в DDL для таблиц, включающих потребительские регистрации или покупки, чтобы избежать делать те таблицы недоступными, по ошибке выпуская дорогое ALTER TABLE оператор.
Для операций DDL с LOCK=SHARED, любые записи к таблице (то есть, операции DML) блокируются, но данные в таблице могут быть считаны. Этот пункт делает ALTER TABLE перестаньте работать, если вид работы DDL не может быть выполнен с требуемым типом блокировки, так что определите LOCK=SHARED если хранение таблицы, доступной для запросов, жизненно важно, и нормально отменять DDL, если это не возможно. Например, Вы могли бы использовать этот пункт в DDL для таблиц в хранилище данных, где нормально задерживать операции загрузки данных, пока DDL не заканчивается, но запросы не могут быть задержаны в течение многих длительных периодов.
Для операций DDL с LOCK=DEFAULT, или с LOCK опущенный пункт, MySQL использует самый низкий уровень блокировки, которая доступна для такой работы, позволяя параллельные запросы, DML, или обоих везде, где возможный. Это - установка, чтобы использовать, производя предварительно запланированные, предварительно протестированные изменения, которые Вы знаете, не будет вызывать проблем доступности, основанных на рабочей нагрузке для той таблицы.
Для операций DDL с LOCK=EXCLUSIVE, блокируются оба запроса и операции DML. Этот пункт делает ALTER TABLE перестаньте работать, если вид работы DDL не может быть выполнен с требуемым типом блокировки, так что определите LOCK=EXCLUSIVE если первоочередная задача заканчивает DDL в самое короткое возможное время, и нормально подавать заявки, ожидают, когда они пытаются получить доступ к таблице. Вы могли бы также использовать LOCK=EXCLUSIVE если сервер, как предполагается, неактивен, избегает неожиданных доступов к таблице.

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

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

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

Производительность Оперативных против Копирующих таблицу Операций DDL

Необработанная производительность онлайновой работы DDL в значительной степени определяется тем, выполняется ли работа оперативная, или требует копирования и восстановления всей таблицы. См. Таблицу 5.8, "Сводка Онлайнового Состояния для Операций DDL", чтобы видеть, какие виды операций могут быть выполнены оперативные, и любые требования для того, чтобы избежать операций табличной копии.

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

Когда работа на использовании первичного ключа ALGORITHM=INPLACE, даже при том, что данные все еще копируются, это более эффективно чем использование ALGORITHM=COPY потому что:

Никакое журналирование отмены или связанное журналирование восстановления не требуются для ALGORITHM=INPLACE. Эти операции добавляют издержки к операторам DDL то использование ALGORITHM=COPY.
Вторичные элементы индекса предварительно сортируются, и так могут быть загружены в порядке.
Буфер изменения не используется, потому что нет никакого произвольного доступа, вставляет во вторичное устройство, индексирует.

Чтобы судить относительную производительность онлайновых операций DDL, можно выполнить такие операции на большом InnoDB таблица используя текущие и более ранние версии MySQL. Можно также выполнить все тесты производительности под последней версией MySQL, моделируя предыдущее поведение DDL для "перед" результатами, устанавливая old_alter_table системная переменная. Сделайте заявление set old_alter_table=1 в сеансе, и определяют эксплуатационные качества DDL, чтобы записать "перед" числами. Затем set old_alter_table=0 повторно включать более новому, более быстрому поведению, и выполнять операции DDL снова, чтобы записать "после" чисел.

Для основной идеи о том, делает ли работа DDL свои оперативные изменения или выполняет табличную копию, смотрите на "строки" значение, на которое влияют, выведенное на экран после того, как команда заканчивается. Например, вот строки, Вы могли бы присматривать за выполнением различных типов операций DDL:

Изменяя значение по умолчанию столбца (сверхбыстрый, не влияет на табличные данные вообще):
```
Query OK, 0 rows affected (0.07 sec)
```
Добавление индексирования (занимает время, но 0 rows affected шоу, что таблица не копируется):
```
Query OK, 0 rows affected (21.42 sec)
```
Изменение типа данных столбца (занимает время и действительно требует восстановления всех строк таблицы):
```
Query OK, 1671168 rows affected (1 min 35.54 sec)
```

Например, прежде, чем выполнить работу DDL на большой таблице, Вы могли бы проверить, будет ли работа быстра или замедлится следующим образом:

Клонируйте структуру таблицы.
Заполните клонированную таблицу с крошечным объемом данных.
Выполните работу DDL на клонированной таблице.
Проверьте, являются ли "строки" значение, на которое влияют, нулем или нет. Ненулевое значение означает, что работа потребует восстановления всей таблицы, которая могла бы потребовать специального планирования. Например, Вы могли бы сделать работу DDL в течение периода запланированного времени простоя, или на каждом ведомом сервере репликации по одному.

Для более глубокого понимания сокращения обработки MySQL исследуйте performance_schema и INFORMATION_SCHEMA таблицы, связанные с InnoDB прежде и после операций DDL, чтобы видеть число физических чтений, записей, выделений памяти, и так далее.