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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Клонируйте структуру таблицы.

  2. Заполните клонированную таблицу с крошечным объемом данных.

  3. Выполните работу DDL на клонированной таблице.

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

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




Spec-Zone.ru - all specs in one place