Поиск

Операторы обслуживания таблиц

Синтаксис ANALYZE TABLE
ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE имя_таблицы[, имя_таблицы] ...
Этот оператор анализирует и сохраняет распределение ключей для таблицы. Во вре­мя анализа таблица блокируется по чтению. Это работает для таблиц MylSAM и BDB, а также (начиная с MySQL 4.0.13) InnoDB. Для таблиц MylSAM данный оператор эквивален­тен myisamchk -a.
MySQL использует сохраненные данные о распределении ключей, чтобы принимать решения относительно порядка объединения таблиц, когда в запросе требуется объеди­нение по неконстантным значениям.
Оператор возвращает таблицу со следующими столбцами:

Вы можете проверить сохраненное распределение ключей с помощью оператора SHOW INDEX. См. раздел Синтаксис SHOW DATABASES
Если таблица не изменялась с последнего выполнения ANALYZE TABLE, ее анализ вы­полняться не будет.
До MySQL 4.1.1 оператор ANALYZE TABLE не записывался в бинарный журнал. Начи­ная с MySQL 4.1.1, он записывается, если только не было указано необязательное клю­чевое слово NO_WRITE_TO_BINLOG (или его псевдоним LOCAL).
<р5> Синтаксис BACKUP TABLE
BACKUP TABLE имя_таблицы[, имя_таблицы] ... ТО '/путь/к/каталогу/резервных_копий%
На заметку!
Этот оператор устарел. Мы работаем над его улучшенной заменой, которая позволит выполнять горячее резервное копирование. А пока вместо этого можно пользоваться сценарием Цmysqlhotcopy.
BACKUP TABLE копирует в резервный каталог минимальный набор файлов таблицы, необходимый для ее последующего восстановления, после сброса всех буферизованных изменений на диск. Этот оператор работает только с таблицами MyISAM. Он копирует файлы определения таблиц .frm и файлы данных .MYD. Индексные файлы .MYI могут быть перестроены на основе первых двух. Каталог должен быть указан с полным путем.
При резервном копировании каждая таблица последовательно блокируется по чте­нию. Если вы хотите скопировать несколько таблиц в виде снимка (предотвращая изменения в них во время резервирования), вы должны сначала выполнить оператор LOCK TABLES, чтобы установить блокировку по чтению для всех таблиц группы.

Оператор BACKUP TABLE доступен в MySQL 3.23.25 и последующих версиях.
Синтаксис CHECK TABLE
CHECK TABLE имя_таблицы [, имя_габлхцы] ... [опция] ... опция = {QUICK | FAST | MEDIUM | EXTENDED | CHANGED}
CHECK TABLE работает только с таблицами MyISAM и InnoDB. Для таблиц MyISAM это то же самое, что и запуск myisamchk —medium-check имя_таблицы.
Если никакая опция не указана, принимается MEDIUM.
Проверяет таблицу или группу таблиц на наличие ошибок. Для таблиц MyISAM обнов­ляется статистическая информация о ключах. Оператор возвращает таблицу со следующими столбцами:

Столбец Значение
Table Имя таблицы
Op Всегда Check
Msg_type Тип: status, error, info или warning
Msg_text Сообщение

Следует отметить, что оператор может выдать множество строк информации о каж­дой проверяемой таблице. Последняя строка будет содержать значение Msg_type, равное status и Msg_text обычно должно быть ОК. Если вы не получаете ОК или же Table is already up to date (Таблица уже обновлена), обычно вы должны будете запустить восстановление таблицы. Сообщение Table is already up to date означает, что механизм хранения сообщает о том, что необходимости проверять таблицу не было.
Существуют следующие типы проверок:

Если не указана ни одна из опций QUICK, MEDIUM или EXTENDED, то по умолчанию для таблиц динамического формата MylSAM выбирается MEDIUM. Типом проверки для статиче­ских таблиц MylSAM также будет MEDIUM, если только не указано CHANGED или FAST. В этом случае по умолчанию выбирается QUICK. Для CHANGED и FAST проверка строк опус­кается, потому что строки очень редко оказываются поврежденными.
Вы можете комбинировать опции проверки, как показано в следующем примере, вы­полняющем быструю проверку таблицу на предмет того, была ли она закрыта правильно:
CHECK TABLE test_table FAST QUICK;
На заметку!
В некоторых случаях CHECK TABLE изменяет таблицу! Это происходит, если таблица помечена, как "поврежденная" или "неправильно закрытая", но CHECK TABLE не находит в ней никаких про­блем. В этом случае CHECK TABLE помечает ее как исправную.
Если таблица повреждена, вероятнее всего, что причина проблем связана с индекса­ми, а не с данными. Все типы проверок включают полную проверку индексов и поэтому в состоянии обнаружить большинство ошибок.
Если вы только хотите проверить таблицу, о которой предполагаете, что с ней все в порядке, вы не должны указывать никаких опций проверки или опцию QUICK. Последняя должна применяться, когда нужно спешить, и риск того, что QUICK не найдет ошибок в файле данных, невелик. (В большинстве случаев при нормальной работе MySQL должен найти любые ошибки в файле данных. Если это происходит, таблица помечается как "поврежденная" и не может использоваться до тех пор, пока не будет восстановлена.)
FAST и CHANGED наиболее хорошо подходят для применения в сценариях (например, выполняемых автоматически демоном сгon), если вы хотите проверять таблицы в соот­ветствие с каким-нибудь графиком. В большинстве случаев опция FAST более предпоч­тительна, нежели CHANGED. (Единственный случай, когда FAST не предпочтительна, это если вы предполагаете, что нашли ошибку в коде MylSAM.)
EXTENDED предназначена для применения только после того, как выполнялась обыч­ная проверка, но происходят странные ошибки при попытках MySQL обновить строку или найти ее по ключу. (Это очень маловероятно, если нормальная проверка заверши­лась успешно.)
Ниже описаны некоторые проблемы, о которых сообщает CHECK TABLE, и которые не могут быть исправлены автоматически.

  • Found row where the auto_increment column has the value 0(Найдена строка, в которой столбец auto_increment имеет значение 0).
    Это означает, что в таблице содержится строка, в которой значение столбца AUTOINCREMENT равно 0. (Существует возможность создать строку со значением столбца AUTO_INCREMENT, равным 0, с помощью оператора UPDATE.)

Это не является ошибкой само по себе, но может вызвать проблемы, если вы ре­шите выгрузить дамп такой таблицы, а затем восстановить ее из дампа либо вы­полнить ALTER TABLE. В этом случае столбец AUTO_INCREMENT изменит значение в соответствии с правилами, действующими относительно таких столбцов, что мо­жет привести к проблеме дублирования ключей.
Чтобы избавиться от упомянутого предупреждения, просто выполните оператор UPDATE и присвойте столбцу значение, отличное от 0.
Синтаксис CHECKSUM TABLE
CHECKSUM TABLE имя_таблицы [, имя_таблицы] ... [ QUICK | EXTENDED ]
Сообщает контрольную сумму таблицы.
Если указана опция QUICK, сообщается актуальная контрольная сумма таблицы, если она доступна, в противном случае выдается null. Это делается очень быстро. Актуаль­ная контрольная сумма включается опцией таблицы CHECKSUM=1, которая в настоящее время поддерживается только для таблиц MyISAM.
При выборе режима EXTENDED выполняется чтение всей таблицы - строка за строкой, и вычисляется контрольная сумма. Для больших таблиц это может происходить очень долго.
По умолчанию, если не указано ни QUICK, ни EXTENDED, MySQL возвращает актуаль­ную контрольную сумму таблицы, если механизм хранения ее поддерживает, либо вы­полняет сканирование таблицы в противном случае.
Оператор реализован в версии MySQL 4.1.1.
Синтаксис OPTIMIZE TABLE
OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE имя_таблицы[, имя_таблицы] ...
OPTIMIZE TABLE необходимо использовать, если удалялась большая часть строк таб­лицы либо выполнялось много изменений в таблице с переменной длиной строки (таб­лицы с столбцами типов VARCHAR, BLOB или text). Удаленные строки помещаются в связ­ный список и последующие операции INSERT повторно используют старые позиции за­писей. Вы можете применять OPTIMIZE TABLE для восстановления неиспользованного пространства и дефрагментации файла данных.
В большинстве случаев вообще нет необходимости вызывать OPTIMIZE TABLE. Даже если вносится множество изменений в строки переменной длины, маловероятно, что вам понадобится делать это чаще раза в неделю или в месяц, да и то - только для некоторых таблиц.
В настоящий момент OPTIMIZE TABLE работает только с таблицами MylSAM и BDB. Причем в случае таблиц BDB оператор OPTIMIZE TABLE отображается на ANALYZE TABLE. См. раздел Синтаксис ANALYZE TABLE
Можно заставить работать optimize table с другими типами таблиц, запустив сер­вер mysqld с опцией —skip-new или —safe-mode, но в этом случае OPTIMIZE TABLE про­сто отображается на ALTER TABLE.
OPTIMIZE TABLE работает так:

  1. Если в таблице есть удаленные или разделенные строки, восстанавливает таблицу.
  2. Если страницы индекса не отсортированы, сортирует их.
  3. Если статистическая информация устарела (и восстановление не может быть выполнено простой сортировкой индекса), обновляет ее.

Отметим, что MySQL блокирует таблицу на время выполнения OPTIMIZE TABLE.
До MySQL 4.1 Л оператор OPTIMIZE TABLE не записывался в бинарный журнал. Начиная с MySQL 4.1.1, он записывается, если только не было указано необбязательное клю­чевое СЛОВО NO_WRITE_TO_BINLOG (или его псевдоним LOCAL).

Синтаксис REPAIR TABLE
REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE
имя_таблицы[, имя_таблицы] ... [QUICK] [EXTENDED] [USE_FRM]
REPAIR TABLE осуществляет восстановление (ремонт) поврежденных таблиц. По умолчанию, он имеет тот же эффект, что и myisamchk —recover имя_таблицы.
REPAIR TABLE работает только с таблицами MyISAM. Обычно вообще нет необходимо­сти вызывать REPAIR TABLE. Однако если неприятность все же возникла, то весьма веро­ятно, что REPAIR TABLE сможет восстановить все ваши данные в таблицах MylSAM. Если ваши таблицы часто получают повреждения, вам нужно найти причину этого, чтобы избежать необходимости часто запускать REPAIR TABLE.
Оператор возвращает таблицу со следующими столбцами:

Оператор REPAIR TABLE может выдать множество строк с информацией о каждой восстанавливаемой таблице. Последняя строка будет содержать значение Msg_type, рав­ное status, и Msg_text обычно должно быть ОК. Если вы не получаете ОК, то вам нужно попробовать восстановить таблицу командой myisamchk —safe-recover, потому что REPAIR TABLE пока не реализует всех возможностей myisamchk. Мы планируем в буду­щем сделать этот оператор более гибким.
Если указано QUICK, REPAIR TABLE пытается восстановить только дерево индекса. Этот тип восстановления аналогичен myisamchk —recover -quick.
Если применяется опция EXTENED, MySQL создает индексы строку за строкой, вместо того, чтобы создавать их сортировкой по одному за раз. (До версии MySQL 4.1 это мо­жет быть лучше, чем сортировка по ключам фиксированной длины, особенно если у вас длинный ключ типа CHAR, который хорошо пакуется.) Этот тип восстановления аналоги­чен myisamchk -safe-recover.
Начиная с MySQL 4.0.2, в REPAIR TABLE добавлен режим USE_FRM. Его следует при­менять, если отсутствует файл индексов .MYI, или если его заголовок поврежден. В этом режиме MySQL пересоздает файл .MYI, используя информацию из файла .frm. Этот спо­соб восстановления невозможно осуществить средствами myisamchk.
Внимание!
Если сервер аварийно завершается во время выполнения оператора REPAIR TABLE, важно по­сле его перезапуска немедленно снова запустить REPAIR TABLE, прежде чем выполнять какие-то манипуляции с таблицей. (Всегда полезно начинать с создания резервной копии.) В худшем случае вы можете получить новый чистый индексный файл, без информации о файле данных, и следующая операция, которую вы попытаетесь выполнить, может перезаписать файл данных. Это маловероятно, но все же возможно.

До MySQL 4.1.1 операторы REPAIR TABLE не записывался в бинарный журнал. Начиная с MySQL 4.1.1, они записываются, если только не было указано необязательное ключевое слово NO_WRITE_TO_BINLOG (или его псевдоним LOCAL).

Синтаксис RESTORE TABLE
RESTORE TABLE имя_таблицы [, имя__таблицы] ... FROM '/'путь/к/каталогу/резервных_копий'
Этот оператор восстанавливает таблицу из резервной копии (не путать с "восстанов­лением" оператором REPAIR TABLE, который, по сути, выполняет ремонт поврежденной таблицы - прим. перев.), которая была создана оператором BACKUP TABLE. Существую­щие таблицы перезаписаны не будут, если вы попытаетесь восстановить поверх сущест­вующей таблицы, то получите сообщение об ошибке. Точно так же, как и BACKUP TABLE, в настоящее время RESTORE TABLE работает только с таблицами MyISAM. Каталог должен быть указан с полным путем.
Резервная копия каждой таблицы состоит из его файла формата . f rm и файла данных .MYD. Операция восстановления из резервной копии возвращает в базу эти файлы, а за­тем строит по ним индексный файл .MYI. Восстановление из копии требует больше вре­мени, чем резервное копирование, поскольку нужно перестраивать индексы. Чем больше у таблицы индексов, тем дольше это происходит.
Оператор возвращает таблицу со следующими столбцами: