Почему я предпочитаю ALGORITHM = COPY для ALGORITHM = INPLACE?

Так как MySQL 5.6 представил интерактивный DDL, ALTER TABLE может также иметь либо ALGORITHM=INPLACE, либо ALGORITHM=COPY. В обзоре онлайн-DDL отмечается, что по умолчанию, INPLACE используется, когда возможно, и подразумевает (даже не заявляя об этом), что INPLACE дешевле, чем код COPY.

Какую причину я должен был бы указать ALGORITHM=COPY на ALTER TABLE

10 голосов | спросил Mark Amery 12 Jpm1000000pmThu, 12 Jan 2017 20:32:26 +030017 2017, 20:32:26

3 ответа


6

Да, бывают случаи, когда вы можете указать COPY, но это было бы по другим причинам, чем производительность.

Важно понимать, что MySQL представил новую функцию - Онлайн-обработку DLL в версии 5.6. Он не удалял автономную обработку. Таким образом, необходимо различать эти два режима:

  1. Некоторые операции все еще работают только в автономном режиме. См. Таблицу 15.10, « «Сводка состояния онлайн для операций DDL » для списка операций DDL, которые могут выполняться или не выполняться на месте.

  2. Операции в режимах Online и Offline имеют немного другое поведение, поэтому вы можете выбрать «старый» для соображений совместимости.

Некоторые примеры (пожалуйста, предложите больше):

  1. Таблицы InnoDB, созданные до того, как MySQL 5.6 не поддерживают ALTER TABLE ... ALGORITHM=INPLACE для таблиц, содержащих временные столбцы (DATE, DATETIME или TIMESTAMP) и не были восстановлены с помощью ALTER TABLE ... ALGORITHM=COPY. В этом случае операция ALTER TABLE ... ALGORITHM=INPLACE возвращает ошибку.

  2. ADD PRIMARY KEY в COPY mode молча преобразует NULL в значения по умолчанию для этого типа данных (0 для INT, пустая строка для varchar), тогда как IN_PLACE не делает этого.

  

С предложением ALGORITHM = COPY операция выполняется успешно, несмотря на   наличие значений NULL в столбцах первичного ключа; данные   тихо изменились, что может вызвать проблемы.

Еще одна причина предпочесть COPY:

  

Операции, для которых вы указываете ALGORITHM = COPY или old_alter_table = 1,   для принудительного выполнения операции копирования таблицы, если это необходимо для точного   обратная совместимость в специализированных сценариях.

Хотя руководство MySQL не говорит о реальных сценариях, вы можете себе представить. Например. разработчик полагался на блокировку таблицы во время операции ALTER INDEX, поэтому таблица доступна только для чтения или полностью заблокирована, и есть процесс, который читает статическую таблицу во время индекса перестраивать.

ответил Stoleg 27 Jpm1000000pmFri, 27 Jan 2017 13:07:03 +030017 2017, 13:07:03
3

@Stoleg, вероятно, имеет лучший ответ, но вот еще один. Понятно, что разработчики оставили =COPY в качестве escape-люка в случае серьезной ошибки в =INLINE. Это позволит пользователям продолжать использовать ALTER, даже если новая функция не работает.

Я видел такие вещи (в флагах, sql_mode, my.cnf и т. д.) на протяжении многих лет. Цель новой версии, несомненно, показать новую, лучшую функцию.

Флаги оптимизации относятся к этой категории, но есть еще больше оснований для зависания предыдущих действий - Оптимизатор всегда будет «делать это неправильно»; существует слишком много возможностей.

ответил Rick James 29 Jam1000000amSun, 29 Jan 2017 08:45:43 +030017 2017, 08:45:43
-1

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

ответил nthdesign 26 PMpThu, 26 Apr 2018 20:25:07 +030025Thursday 2018, 20:25:07

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132