REPAIR [NO_WRITE_TO_BINLOG | LOCAL] 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, ARCHIVE, and
CSV tables. See
Section 15.3, “The MyISAM Storage Engine”,
Section 15.6, “The ARCHIVE Storage Engine”, and
Section 15.5, “The CSV Storage Engine”. This statement does not
work with views.
This statement requires SELECT
and INSERT privileges for the
table.
REPAIR TABLE is supported for
partitioned tables. However, the USE_FRM
option cannot be used with this statement on a partitioned
table.
You can use ALTER TABLE ... REPAIR PARTITION
to repair one or more partitions; for more information, see
Section 13.1.7, “ALTER TABLE Syntax”, and
Section 19.3.3, “Maintenance of Partitions”.
Normally, you should never have to run
REPAIR TABLE. However, if
disaster strikes, this statement 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 B.5.3.3, “What to Do If MySQL Keeps Crashing”, and
Section 15.3.4, “MyISAM Table Problems”.
It is best to make a backup of a table before performing a table repair operation; under some circumstances the operation might cause data loss. Possible causes include but are not limited to file system errors. See Chapter 7, Backup and Recovery.
If the server crashes 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. 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 that underscores the value of making a
backup first.
REPAIR TABLE returns a result set
with the following columns.
| Column | Value |
|---|---|
Table | The table name |
Op | Always repair |
Msg_type | status, error,
info, note, or
warning |
Msg_text | An informational message |
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 for a MyISAM table, you
should try repairing it with myisamchk
--safe-recover. (REPAIR
TABLE does not implement all the options of
myisamchk.) With myisamchk
--safe-recover, you can also use options that
REPAIR TABLE does not support,
such as --max-record-length.
If you use the QUICK option,
REPAIR TABLE tries to repair only
the index file, and not the data file. This type of repair is
like that done by myisamchk --recover
--quick.
If you use the EXTENDED option, 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.
The USE_FRM option is available for use if
the .MYI index file is missing or if its
header is corrupted. This option tells MySQL not to trust the
information in the .MYI file header and to
re-create it using information from the
.frm file. This kind of repair cannot be
done with myisamchk.
Use the USE_FRM option
only if you cannot use regular
REPAIR modes. Telling the server to ignore
the .MYI file makes important table
metadata stored in the .MYI unavailable
to the repair process, which can have deleterious
consequences:
The current AUTO_INCREMENT value is
lost.
The link to deleted records in the table is lost, which means that free space for deleted records will remain unoccupied thereafter.
The .MYI header indicates whether the
table is compressed. If the server ignores this
information, it cannot tell that a table is compressed and
repair can cause change or loss of table contents. This
means that USE_FRM should not be used
with compressed tables. That should not be necessary,
anyway: Compressed tables are read only, so they should
not become corrupt.
If you use USE_FRM for a table that was
created by a different version of the MySQL server than the
one you are currently running, REPAIR
TABLE will not attempt to repair the table. In this
case, the result set returned by REPAIR
TABLE contains a line with a
Msg_type value of error
and a Msg_text value of Failed
repairing incompatible .FRM file.
If USE_FRM is not used,
REPAIR TABLE checks the table to
see whether an upgrade is required. If so, it performs the
upgrade, following the same rules as
CHECK TABLE ... FOR
UPGRADE. See Section 13.7.2.2, “CHECK TABLE Syntax”, for more
information. REPAIR TABLE without
USE_FRM upgrades the
.frm file to the current version.
By default, the server writes REPAIR
TABLE statements to the binary log so that they
replicate to replication slaves. To suppress logging, specify
the optional NO_WRITE_TO_BINLOG keyword or
its alias LOCAL.
In the event that a table on the master becomes corrupted and
you run REPAIR TABLE on it, any
resulting changes to the original table are
not propagated to slaves.
You may be able to increase REPAIR
TABLE performance by setting certain system variables.
See Section 8.6.3, “Speed of REPAIR TABLE Statements”.
As of MySQL 5.5.6, REPAIR TABLE
table catches and throws any errors that occur while copying
table statistics from the old corrupted file to the newly
created file. For example. if the user ID of the owner of the
.frm, .MYD, or
.MYI file is different from the user ID of
the mysqld process,
REPAIR TABLE generates a "cannot
change ownership of the file" error unless
mysqld is started by the
root user.