It is best to make a backup of a table before performing a
table repair operation; under some circumstances the operation
might cause data loss. Possible causes include but are not
limited to file system errors. See
Chapter 7, Backup and Recovery.

Warning

If the server crashes 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. 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 that underscores the value of making a
backup first.

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.

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
.frm file. This kind of repair cannot be
done with myisamchk.

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 will remain
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.

Caution

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 will 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.

By default, the server writes REPAIR
TABLE statements to the binary log so that they
replicate to replication slaves. To suppress logging, specify
the optional NO_WRITE_TO_BINLOG keyword or
its alias LOCAL.

Important

In the event that a table on the master becomes corrupted and
you run REPAIR TABLE on it, any
resulting changes to the original table are
not propagated to slaves.

As of MySQL 5.5.6, 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
.frm, .MYD, or
.MYI file is different from the user ID of
the mysqld process,
REPAIR TABLE generates a "cannot
change ownership of the file" error unless
mysqld is started by the
root user.

the character sets dir configuration was missing and no tables repair was needed.

i had a strange issue.i had upgraded mysql from public repository with apt-getand after then had disk full error and had to restart.after repairing the disk full error i have discovered the data selected from tables is gibberish.in phpmyadmin the type of all tables was VIEW and they all ware corrupt even if i repair them or optimize or check... and when i repair it with myisamchk it does nothing.just shows :myisamchk -eron emaillist, the errors:- recovering (with sort) MyISAM-table 'emaillist'Data records: 4255- Fixing index 1Found link that points at -1735598930481103523 (outside data file) at 27888Found block that points outside data file at 268252Found block that points outside data file at 268572Found block that points outside data file at 268844Found block that points outside data file at 268916

and nothing was changed after the repair.

in phpmyadmin when i click on a table it selected SHOW FULL COLUMNS and it showd an error similar to: the table is corrupt unknown COLLATIONS #16 error #1273

i have started to search, where are those collation numbers came from, and found that in mysql schema database there is a collations tableand my number 16 was missingand i saw that the list is suspiciously small.when i ran 'mysql --help' there was no charset directory

the solution was to set the in my.cnf[mysqld]character-sets-dir=/usr/share/mysql/charsets

and it worked like a charm

Posted by
Victor Praigs
on
March 1, 2014

You can repair & restore your corrupt MySQL database by MySQL Repair Toolbox. It is read only in nature and successful restore table corruption in MySQL database. You can download free demo version to see the preview of your corrupt database.