Двоичное обновление или упадок являются тем, который устанавливает одну версию MySQL "на месте" по существующей версии, не выводя и перезагружая таблицы:

Во многих случаях таблицы от предыдущей версии MySQL могут использоваться без проблемы новой версией. Однако, иногда изменения происходят, которые требуют таблиц, или таблица индексирует, чтобы быть восстановленной, как описано в этом разделе. Если у Вас есть таблицы, на которые влияет любая из проблем, описанных здесь, восстанавливают таблицы, или индексирует по мере необходимости использование инструкций, данных в Разделе 2.11.4, "Восстановление или Восстановление Таблиц, или Индексирует".

Табличные Несовместимости

После двоичного обновления до MySQL 5.1 от установки MySQL 5.0, которая содержит ARCHIVE таблицы, получая доступ к тем таблицам заставляют сервер отказывать, даже если Вы выполнили mysql_upgrade или CHECK TABLE ... FOR UPGRADE. Чтобы работать вокруг этой проблемы, используйте mysqldump, чтобы вывести все ARCHIVE таблицы перед обновлением, и перезагружают их в MySQL 5.1 после обновления. Та же самая проблема происходит для двоичных упадков от MySQL 5.1 до 5.0.

Проблема обновления решается в MySQL 5.6.4: сервер может открыться ARCHIVE таблицы составляются в MySQL 5.0. Однако, остается рекомендуемой процедурой обновления выводить 5.0 ARCHIVE таблицы прежде, чем обновить и перезагружают их после обновления.

Индексируйте Несовместимости

В MySQL 5.6.3 предел длины для индексирует префиксные ключи, увеличивается от 767 байтов до 3072 байтов, для InnoDB табличное использование ROW_FORMAT=DYNAMIC или ROW_FORMAT=COMPRESSED. См. Раздел 14.2.7, "Пределы на InnoDB Таблицы" для деталей. Это изменение также бэкпортируется к MySQL 5.5.14. Если Вы понижаете от одного из этих выпусков или выше к более раннему выпуску с более низким пределом длины, индексировать префиксные ключи могли быть усеченными в 767 байтах, или упадок мог перестать работать. Эта проблема могла только произойти если параметр конфигурации innodb_large_prefix был включен на понижаемом сервере.

Если Вы выполняете двоичное обновление, не выводя и перезагружая таблицы, невозможно обновить непосредственно от MySQL 4.1 до 5.1 или выше. Это происходит из-за несовместимого изменения в MyISAM таблица индексирует формат в MySQL 5.0. Обновление от MySQL 4.1 до 5.0 и восстановление все MyISAM таблицы. Затем обновление от MySQL 5.0 до 5.1 и проверка и восстановление Ваши таблицы.

Модификации к обработке наборов символов или сопоставлений могли бы изменить символьный порядок сортировки, который вызывает упорядочивание записей в любом, индексируют, который использует набор символов, на который влияют, или сопоставление, чтобы быть неправильным. Такие изменения приводят к нескольким возможным проблемам:

Решение этих проблем состоит в том, чтобы восстановить, любой индексирует то использование набор символов, на который влияют, или сопоставление, или отбрасывая и воссоздавая индексирование, или выводя и перезагружая всю таблицу. В некоторых случаях возможно изменить столбцы, на которые влияют, чтобы использовать различное сопоставление. Для получения информации о восстановлении индексирует, см. Раздел 2.11.4, "Восстанавливая или Восстанавливая Таблицы, или Индексирует".

Проверять, имеет ли таблица, индексирует, который должен быть восстановлен, консультироваться со следующим списком. Это указывает, какие версии MySQL представленные изменения набора символов или сопоставления, которые требуют, индексируют, чтобы быть восстановленными. Каждая запись указывает на версию, в которой изменение произошло и наборы символов или сопоставления, на которые влияет изменение. Если изменение связывается с определенным отчетом об ошибках, число ошибки дается.

Список применяется и для двоичных обновлений и для упадков. Например, Ошибка #27877 была исправлена в MySQL 5.1.24, таким образом, это применяется к обновлениям от версий, более старых чем 5.1.24 к 5.1.24 или более новый, и к упадкам от 5.1.24 или более новый для версий, более старых чем 5.1.24.

Во многих случаях можно использовать CHECK TABLE ... FOR UPGRADE идентифицировать таблицы, для которых индексируют восстановление, требуется. Это сообщит об этом сообщении:

Table upgrade required.Please do "REPAIR TABLE `tbl_name`" or dump/reload to fix it!

В этих случаях можно также использовать mysqlcheck - обновление проверки или mysql_upgrade, которые выполняются CHECK TABLE. Однако, использование CHECK TABLE применяется только после обновлений, не упадков. Кроме того, CHECK TABLE не применимо ко всем механизмам хранения. Для получения дополнительной информации то, о который механизмы хранения CHECK TABLE поддерживает, см. Раздел 13.7.2.2,"CHECK TABLE Синтаксис".

Эти изменения причина индексируют восстановление, чтобы быть необходимыми: