| [ < ] | [ > ] | [ << ] | [ 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] | [ ? ] |