Да, есть случаи, когда вы можете указать COPY
, но это будет по другим причинам, кроме производительности.
Важно понимать, что MySQL представил новую функцию - онлайн-обработку DLL в версии 5.6. Это не удаляет автономную обработку. Поэтому необходимо различать эти 2 режима:
Некоторые операции все еще работают только в автономном режиме. См. Таблицу 15.10, « Сводка онлайн-статуса для операций DDL » для получения списка операций DDL, которые могут или не могут быть выполнены на месте.
Операции в оперативном и автономном режимах имеют несколько различное поведение, поэтому вы можете выбрать «старый» по причинам совместимости.
Некоторые примеры (пожалуйста, предложите больше):
InnoDB таблицы , созданные до MySQL 5.6 не поддерживает ALTER TABLE ... ALGORITHM=INPLACE
для таблиц , которые включают в себя временные столбцы ( DATE
, DATETIME
или TIMESTAMP
) и не были реконструированы с использованием ALTER TABLE ... ALGORITHM=COPY
. В этом случае ALTER TABLE ... ALGORITHM=INPLACE
операция возвращает ошибку.
ADD PRIMARY KEY
Предложение in COPY mode
тихо преобразует NULL
значения по умолчанию для этого типа данных (0 для INT, пустая строка для varchar), тогда IN_PLACE
как не делает этого.
С предложением ALGORITHM = COPY операция завершается успешно, несмотря на наличие значений NULL в столбцах первичного ключа; данные молча меняются, что может вызвать проблемы.
Еще одна причина, чтобы предпочесть COPY
:
Операции, для которых вы указываете ALGORITHM = COPY или old_alter_table = 1, чтобы принудительно принудительно копировать таблицу при необходимости для точной обратной совместимости в специализированных сценариях.
Хотя руководство MySQL не говорит о реальных сценариях, вы можете себе представить некоторые из них. Например, разработчик полагался на то, что таблица заблокирована во время ALTER INDEX
работы, поэтому таблица доступна только для чтения или полностью заблокирована, и существует процесс, который читает статическую таблицу во время перестроения индекса.