Spec-Zone .ru
спецификации, руководства, описания, API

13.7.2.5. REPAIR TABLE Синтаксис

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

REPAIR TABLE восстанавливает возможно поврежденную таблицу, для определенных механизмов хранения только. По умолчанию это имеет тот же самый эффект, как myisamchk - восстанавливаются tbl_name.

Отметить

REPAIR TABLE только применяется к MyISAM, ARCHIVE, и CSV таблицы. См. Раздел 14.3," MyISAM Механизм хранения", и Раздел 14.6," ARCHIVE Механизм хранения", и Раздел 14.5," CSV Механизм хранения"

Этот оператор требует SELECT и INSERT полномочия для таблицы.

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

В MySQL 5.6.11 только, gtid_next должен быть установлен в AUTOMATIC прежде, чем сделать это заявление. (Ошибка #16062608, Ошибка #16715809, Ошибка #69045)

Можно использовать ALTER TABLE ... REPAIR PARTITION восстановить один или более разделов; для получения дополнительной информации см. Раздел 13.1.7,"ALTER TABLE Синтаксис", и Раздел 18.3.4, "Обслуживание Разделов".

Хотя обычно Вам никогда не придется работать REPAIR TABLE, если бедствие ударит, то этот оператор, очень вероятно, возвратит все Ваши данные от a MyISAM таблица. Если Ваши таблицы становятся поврежденными часто, попытайтесь найти причину этого, избавить от необходимости использовать REPAIR TABLE. См. Раздел C.5.4.2, "Что к MySQL Do If Продолжает Отказывать", и Раздел 14.3.4,"MyISAM Табличные проблемы".

Предостережение

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

Предупреждение

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

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

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

REPAIR TABLE оператор мог бы произвести много строк информации для каждой восстановленной таблицы. У последней строки есть a Msg_type значение status и Msg_test обычно должен быть OK. Если Вы не добираетесь OK для a MyISAM таблица, следует попытаться восстановить это с myisamchk - безопасный - восстанавливаются. (REPAIR TABLE не реализует все опции myisamchk.) С myisamchk - безопасный - восстанавливаются, можно также использовать опции это REPAIR TABLE не поддерживает, такой как --max-record-length.

Если Вы используете QUICK опция, REPAIR TABLE попытки восстановить только индексный файл, а не файл данных. Этот тип восстановления походит, сделанное myisamchk - восстанавливается - быстрый.

Если Вы используете EXTENDED опция, MySQL создает индексировать строку строкой вместо того, чтобы создать, каждый индексирует за один раз с сортировкой. Этот тип восстановления походит, сделанное myisamchk - безопасный - восстанавливается.

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

Отметить

Используйте USE_FRM опция, только если невозможно использовать регулярный REPAIR режимы! Сообщение сервера проигнорировать .MYI файл делает важные табличные метаданные сохраненными в .MYI недоступный к процессу восстановления, у которого могут быть вредные последствия:

  • Ток AUTO_INCREMENT значение теряется.

  • Ссылка к удаленным записям в таблице теряется, что означает, что свободное пространство для удаленных записей останется незанятым после того.

  • .MYI заголовок указывает, сжимается ли таблица. Если сервер игнорирует эту информацию, он не может сказать, что таблица сжимается, и восстановление может вызвать изменение или потерю табличного содержания. Это означает это USE_FRM не должен использоваться со сжатыми таблицами. Это не должно быть необходимо, так или иначе: Сжатые таблицы только для чтения, таким образом, они не должны стать поврежденными.

Предостережение

Если Вы используете USE_FRM для таблицы, которая была составлена различной версией сервера MySQL чем тот, который Вы являетесь в настоящий момент рабочими, REPAIR TABLE не будет пытаться восстановить таблицу. В этом случае, набор результатов, возвращенный REPAIR TABLE содержит строку с a Msg_type значение error и a Msg_text значение Failed repairing incompatible .FRM file.

Если USE_FRM не используется, REPAIR TABLE проверяет таблицу, чтобы видеть, требуется ли обновление. Если так, это выполняет обновление, после тех же самых правил как CHECK TABLE ... FOR UPGRADE. См. Раздел 13.7.2.2,"CHECK TABLE Синтаксис", для получения дополнительной информации. REPAIR TABLE без USE_FRM обновления .frm файл к текущей версии.

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

Важный

Когда таблица на ведущем устройстве становится поврежденной, и Вы работаете REPAIR TABLE на этом любые получающиеся изменения к исходной таблице не распространяются к ведомым устройствам.

Можно быть в состоянии увеличиться REPAIR TABLE производительность, устанавливая определенные системные переменные. См. Раздел 8.6.3, "Скорость REPAIR TABLE Операторы".

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