content_image/783500.jpg
If you use the EXTENDED  option, 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 . 

• USE_FRM 

The USE_FRM  option is available for use if the .MYI  index file is missing or if its header is corrupted. This option tells MySQL not to trust the information in the .MYI  file header and to re-create it using information from the data dictionary. This kind of repair cannot be done with myisamchk . 

## REPAIR TABLE Output 

## Caution 

Use the USE_FRM  option only  if you cannot use regular REPAIR  modes. Telling the server to ignore the .MYI  file makes important table metadata stored in the .MYI  unavailable to the repair process, which can have deleterious consequences: 

•The current AUTO_INCREMENT  value is lost. 

•The link to deleted records in the table is lost, which means that free space for deleted records remains unoccupied thereafter. 

•The .MYI  header indicates whether the table is compressed. If the server ignores this information, it cannot tell that a table is compressed and repair can cause change or loss of table contents. This means that USE_FRM  should not be used with compressed tables. That should not be necessary, anyway: Compressed tables are read only, so they should not become corrupt. 

If you use USE_FRM  for a table that was created by a different version of the MySQL server than the one you are currently running, REPAIR TABLE  does not attempt to repair the table. In this case, the result set returned by REPAIR TABLE  contains a line with a Msg_type  value of error  and a Msg_text  value of Failed repairing incompatible .FRM file . 

If USE_FRM  is used, REPAIR TABLE  does not check the table to see whether an upgrade is required. 

REPAIR TABLE  returns a result set with the columns shown in the following table. 

<img src='content_image/783500.jpg'>

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 . For a MyISAM  table, if you do not get OK , you should try repairing it with myisamchk --safe-recover . ( REPAIR TABLE  does not implement all the options of myisamchk . With myisamchk --safe-recover , you can also use options that REPAIR TABLE  does not support, such as --max-record-length .) 

REPAIR TABLE  table catches and throws any errors that occur while copying table statistics from the old corrupted file to the newly created file. For example. if the user ID of the owner of the .MYD  or .MYI  file is 

