REPAIRTABLE syntax-MySQL database bitsCN.com
[Pre] REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE [/pre] [pre] tbl_name [, tbl_name]... [QUICK] [EXTENDED] [USE_FRM] [/pre] repair table is used to REPAIR damaged tables. By default, the repair table and myisamchk -- recovertbl_name have the same effect. Repair table applies to MyISAM and ARCHIVE tables.
Generally, you do not have to run this statement. However, if a disaster occurs, the repair table may retrieve all data from the MyISAM TABLE. If your table is often damaged, you should try your best to find the cause to avoid using repair talbe. See section A.4.2, "What should I do if MySQL still crashes ". For more information, see section 15.1.4 "MyISAM table problems ".
This statement returns a table containing the following columns:
For each repaired TABLE, the repair table statement generates multiple rows of information. The previous row contains a Msg_type status value. Msg_test should generally be OK. If you do not get OK, you should try to use myisamchk -- safe-recover to REPAIR the TABLE, because REPAIR TABLE does not execute all myisamchk options yet. 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 similar to using myisamchk -- recover -- quick.
If you use EXTENDED, MySQL creates an index row in one row instead of a category. This type of repair is similar to using myisamchk -- safe-recover.
For repair table, another USE_FRM mode can be used. This mode is used if the. MYI index file is missing or the title is damaged. In this mode, MySQL can use the. frm file to recreate the. MYI file. You cannot use myisamchk to fix this problem. Note: This mode can only be used when you cannot use the regular REPAIR mode .. The MYI title contains important table metadata (especially the current AUTO_INCREMENT value and Delete link ). These metadata is lost in REPAIR... USE_FRM. If the table is compressed, USE_FRM cannot be used. This information is also stored in the. MYI file.
The repair table statement is written to the binary log unless the NO_WRITE_TO_BINLOG keyword (or its alias is LOCAL) is used ).
Warning if the server is down while the repair table is running, you must execute another repair table statement immediately after the restart and before other operations are performed. (It is a good way to start a backup .) In the worst case, you can have a new clean index file that does not contain information about the data file. The next operation you perform will overwrite the data file. This rarely happens, but it is possible.
BitsCN.com