[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
REPAIR TABLE
Syntax
REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...] [QUICK] [EXTENDED] [USE_FRM] |
REPAIR TABLE
works only on MyISAM
tables and is the same
as running myisamchk -r table_name
on the table.
Normally you should never have to run this command, but if disaster strikes,
you are very likely to get back all your data from a MyISAM table with
REPAIR TABLE
. If your tables get corrupted often, you should
try to find the reason for it, to eliminate the need to use REPAIR
TABLE
.
See section A.4.1 What To Do If MySQL Keeps Crashing. See section 14.1.3 MyISAM
Table Problems.
REPAIR TABLE
repairs a possibly corrupted table. The command returns a
table with the following columns:
Column | Value |
Table | Table name |
Op | Always repair |
Msg_type | One of status , error , info , or warning |
Msg_text | The message |
Note that the statement might produce many rows of information for each repaired
table.
The last one row will be of Msg_type status
and should
normally be OK
.
If you don't get OK
, you should try
repairing the table with myisamchk --safe-recover
, because REPAIR TABLE
does not yet implement all the options of myisamchk
. In the near
future, we will make it more flexible.
If QUICK
is given, REPAIR TABLE
tries to repair
only the index tree.
If you use EXTENDED
, MySQL creates the index row
by row instead of creating one index at a time with sorting; this might be
better than sorting on fixed-length keys if you have long CHAR
keys that compress very well. This type of repair is like that done by
myisamchk --safe-recover
.
As of MySQL
4.0.2, there is a USE_FRM
mode for REPAIR
.
Use it if the `.MYI' file is missing or if its header is corrupted.
In this mode MySQL will re-create the table, using information from the
`.frm' file. This kind of repair cannot be done with myisamchk
.
Warning: If mysqld
dies during a REPAIR TABLE
,
it's essential that you do at once another REPAIR
on the table
before executing any other commands on it. (It's always good
to start by making a backup). In the worst case you can have a new clean
index file without information about the datafile and when the next
command you do may overwrite the datafile. This is not a likely, but
possible scenario.
Before MySQL 4.1.1, REPAIR
commands are not written
to the binary log. Since MySQL 4.1.1 they are written to the binary
log unless the optional NO_WRITE_TO_BINLOG
keyword
(or its alias LOCAL
) was used.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |