(mysql.info) repair-table

(mysql.info) table-maintenance-sql
 
 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 
 myisam-storage-engine, and  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  crashing, and  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:
 
 *Column*    *Value*
 `Table'     The table name
 `Op'        Always `repair'
 `Msg_type'  One of `status', `error', `info', or
             `warning'
 `Msg_text'  The 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', 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'.
 * 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.
Info Catalog
(mysql.info) optimize-table
(mysql.info) table-maintenance-sql
(mysql.info) restore-table
automatically generated byinfo2html