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.