(mysql.info.gz) REPAIR TABLE

(mysql.info.gz) 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 only on `MyISAM' tables.
 
 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'.   Crashing.   `MyISAM' table problems
 MyISAM table problems.
 
 The statement returns a table 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 will have a `Msg_type' value of
 `status' and `Msg_test' normally should 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'. We plan to make it more flexible in the future.
 
 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.  (Before MySQL 4.1, 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 TABLE'.  Use
 it if the `.MYI' index file is missing or if its header is corrupted.
 In this mode, MySQL will re-create 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 will
 be lost in `REPAIR ... USE_FRM'.  Don't use `USE_FRM' if the table is
 compressed, as this information is also stored in `.MYI' file.
 
 Before MySQL 4.1.1, `REPAIR TABLE' statements are not written to the
 binary log. As of MySQL 4.1.1, they are written to the binary log
 unless the optional `NO_WRITE_TO_BINLOG' keyword (or its alias `LOCAL')
 is used.
 
 *Warning:* If the server dies during a `REPAIR TABLE' operation, it's
 essential after restarting it that you immediately execute another
 `REPAIR TABLE' statement for the table before performing any other
 operations on it. (It's always good 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.
Info Catalog
(mysql.info.gz) OPTIMIZE TABLE
(mysql.info.gz) Table maintenance SQL
(mysql.info.gz) RESTORE TABLE
automatically generated byinfo2html