13.5.2.6. REPAIR TABLE Syntax
REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE
tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]
REPAIR TABLE repairs a possibly corrupted
table. By default, it has the same effect as
myisamchk --recover
tbl_name. REPAIR
TABLE works for MyISAM and for
ARCHIVE tables. See
Section 14.1, “The MyISAM Storage Engine”, and
Section 14.8, “The ARCHIVE Storage Engine”.
Normally, you should never have to run this statement.
However, if disaster strikes, REPAIR TABLE
is very likely to get back all your data from a
MyISAM table. If your tables become
corrupted often, you should try to find the reason for it, to
eliminate the need to use REPAIR TABLE. See
Section A.4.2, “What to Do If MySQL Keeps Crashing”, and
Section 14.1.4, “MyISAM Table Problems”.
Warning: If the server dies
during a REPAIR TABLE operation, it is
essential after restarting it that you immediately execute
another REPAIR TABLE statement for the
table before performing any other operations on it. (It is
always a good idea to start by making a backup.) In the worst
case, you might have a new clean index file without
information about the data file, and then the next operation
you perform could overwrite the data file. This is an unlikely
but possible scenario.
REPAIR TABLE returns a result set with the
following columns:
The REPAIR TABLE statement might produce
many rows of information for each repaired table. The last row
has a Msg_type value of
status and Msg_test
normally should be OK. If you do not get
OK, you should try repairing the table with
myisamchk --safe-recover. (REPAIR
TABLE does not yet implement all the options of
myisamchk. We plan to make it more flexible
in the future.) With myisamchk
--safe-recover, you can also use options that
REPAIR TABLE does not support, such as
--max-record-length.
If QUICK is given, REPAIR
TABLE tries to repair only the index tree. This type
of repair is like that done by myisamchk --recover
--quick.
If you use EXTENDED, MySQL creates the
index row by row instead of creating one index at a time with
sorting. This type of repair is like that done by
myisamchk --safe-recover.
There is also a USE_FRM mode available for
REPAIR TABLE. Use this if the
.MYI index file is missing or if its
header is corrupted. In this mode, MySQL re-creates the
.MYI file using information from the
.frm file. This kind of repair cannot be
done with myisamchk.
Note: Use this mode
only if you cannot use regular
REPAIR modes. .MYI
header contains important table metadata (in particular,
current AUTO_INCREMENT value and
Delete link) that are lost in
REPAIR ... USE_FRM. Don't use
USE_FRM if the table is compressed because
this information is also stored in the
.MYI file.
REPAIR TABLE statements are written to the
binary log unless the optional
NO_WRITE_TO_BINLOG keyword (or its alias
LOCAL) is used. This is done so that
REPAIR TABLE statements used on a MySQL
server acting as a replication master will be replicated by
default to the replication slave.