13.7.2.5 REPAIR TABLE Statement — MySQL 5.7

13.7.2.5 Выполнение команды REPAIR TABLE

REPAIR [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name [, tbl_name] ...
    [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE восстанавливает, возможно, повреждённую таблицу, только для определённых типов движков хранения.

Для выполнения этой команды требуется SELECT и INSERT для таблицы.

Хотя обычно использовать REPAIR TABLE не нужно, в случае катастрофы эта команда, скорее всего, восстановит все данные из повреждённой MyISAM таблицы. Если ваши таблицы часто повреждаются, постарайтесь найти причину, чтобы избежать использования REPAIR TABLE. Обратитесь к Разделу B.3.3.3, «Что делать, если MySQL продолжает аварийно завершаться» и Разделу 15.2.4, «Проблемы с таблицами MyISAM».

REPAIR TABLE проверяет таблицу на необходимость обновления. Если это необходимо, выполняется обновление по тем же правилам, что и для CHECK TABLE ... FOR UPGRADE. Дополнительную информацию см. в Разделе 13.7.2.2, «Выполнение команды CHECK TABLE».

Важно

Сделайте резервную копию таблицы перед выполнением операции по восстановлению; в некоторых случаях операция может привести к потере данных. Возможные причины включают, но не ограничиваются ими, ошибки файловой системы. См. Главу 7, Резервное копирование и восстановление.
Если сервер завершает работу во время операции REPAIR TABLE, после его перезапуска необходимо немедленно выполнить другую команду REPAIR TABLE для таблицы перед выполнением любых других операций с ней. В худшем случае у вас может быть новый чистый индексный файл без информации о файле данных, а затем следующая выполняемая операция может перезаписать файл данных. Это маловероятный, но возможный сценарий, который подчеркивает важность резервного копирования.
В случае повреждения таблицы на источнике и выполнения операции REPAIR TABLE, любые последующие изменения в исходной таблице не распространяются на реплики.

Поддержка REPAIR TABLE для движков хранения и разбиения таблиц

REPAIR TABLE работает с таблицами MyISAM, ARCHIVE и CSV. Для таблиц MyISAM по умолчанию она эквивалентна myisamchk --recover tbl_name. Данная команда не работает с представлениями.

REPAIR TABLE поддерживается для разбиений таблиц. Однако, опция USE_FRM не может быть использована с данной командой для разбиений таблиц.

Можно использовать ALTER TABLE ... REPAIR PARTITION для восстановления одной или нескольких партиций; для получения дополнительной информации см. Раздел 13.1.8, «Команда ALTER TABLE» и Раздел 22.3.4, «Обслуживание партиций».

Параметры команды REPAIR TABLE

NO_WRITE_TO_BINLOG или LOCAL

По умолчанию сервер записывает REPAIR TABLE в бинарный журнал для репликации на реплики. Для отключения ведения журнала укажите необязательное ключевое слово NO_WRITE_TO_BINLOG или его псевдоним LOCAL.
QUICK

Если используется опция QUICK, REPAIR TABLE пытается восстановить только индексный файл, а не файл данных. Этот тип восстановления аналогичен восстановлению, выполняемому командой myisamchk --recover --quick.
EXTENDED

При использовании опции EXTENDED MySQL создаёт строки индексов поочерёдно вместо создания одного индекса за раз с сортировкой. Этот тип восстановления аналогичен восстановлению, выполняемому командой myisamchk --safe-recover.
USE_FRM

Опция USE_FRM доступна, если индексный файл .MYI отсутствует или его заголовок повреждён. Эта опция указывает MySQL не доверять информации в заголовке файла .MYI и пересоздать его, используя информацию из файла .frm. Такой тип восстановления не может быть выполнен с помощью команды myisamchk.
Внимание

Используйте опцию USE_FRM только в том случае, если вы не можете использовать стандартные режимы REPAIR. Указание серверу игнорировать файл .MYI делает недоступными важные метаданные таблицы, хранящиеся в файле .MYI, для процесса восстановления, что может привести к негативным последствиям:
- Текущее значение AUTO_INCREMENT теряется.
- Связь с удалёнными записями в таблице теряется, что означает, что освобождённое пространство для удалённых записей остаётся неиспользованным.
- Заголовок .MYI указывает, сжата ли таблица. Если сервер игнорирует эту информацию, он не может определить, что таблица сжата, и восстановление может привести к изменению или потере содержимого таблицы. Это означает, что USE_FRM не следует использовать со сжатыми таблицами. Это вообще не должно потребоваться: сжатые таблицы доступны только для чтения, поэтому они не должны повреждаться.
Если вы используете USE_FRM для таблицы, созданной другой версией MySQL, чем та, которую вы используете в настоящее время, REPAIR TABLE не пытается восстановить таблицу. В этом случае результат набора возвращаемых значений REPAIR TABLE содержит строку со значением Msg_type равным error и значением Msg_text равным Failed repairing incompatible .FRM file.

При использовании USE_FRM, REPAIR TABLE не проверяет таблицу на необходимость обновления.

Вывод таблицы REPAIR

REPAIR TABLE возвращает набор результатов со столбцами, показанными в следующей таблице.

Столбец	Значение
`Table`	Имя таблицы
`Op`	Всегда `repair`
`Msg_type`	`status`, `error`, `info`, `note` или `warning`
`Msg_text`	Информационное сообщение

Команда REPAIR TABLE может генерировать много строк информации для каждой отремонтированной таблицы. Последняя строка имеет значение Msg_type, равное status, и Msg_test обычно должно быть OK. Для таблицы MyISAM, если вы не получаете OK, вы должны попробовать отремонтировать её с помощью myisamchk --safe-recover. (REPAIR TABLE не реализует все опции myisamchk. С myisamchk --safe-recover вы также можете использовать опции, которые REPAIR TABLE не поддерживает, такие как --max-record-length.)

REPAIR TABLE ловит и обрабатывает любые ошибки, возникающие при копировании статистических данных таблицы из старого поврежденного файла в новый созданный. Например, если идентификатор пользователя владельца файла .frm, .MYD или .MYI отличается от идентификатора пользователя процесса mysqld, REPAIR TABLE генерирует ошибку «невозможно изменить владение файлом», если mysqld не запущен пользователем root.

Учёт при ремонте таблиц

REPAIR TABLE обновляет таблицу, если она содержит старые временные столбцы в формате до 5.6.4 (TIME, DATETIME и TIMESTAMP столбцы без поддержки точности долей секунды), и системная переменная avoid_temporal_upgrade отключена. Если avoid_temporal_upgrade включена, REPAIR TABLE игнорирует старые временные столбцы в таблице и не обновляет их.

Чтобы обновить таблицы, содержащие такие временные столбцы, отключите avoid_temporal_upgrade перед выполнением REPAIR TABLE.

Вы можете повысить производительность REPAIR TABLE путем настройки определённых системных переменных. См. Раздел 8.6.3, «Оптимизация команд REPAIR TABLE».