Да, есть случаи, когда вы можете указать 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работы, поэтому таблица доступна только для чтения или полностью заблокирована, и существует процесс, который читает статическую таблицу во время перестроения индекса.