myisamchk supports the following options for table repair operations:
Make a backup of the .MYD file as
file_name-time.BAK
The directory where character sets are installed. See Section 5.10.1, “The Character Set Used for Data and Sorting”.
Correct the checksum information for the table.
--data-file-length=
len,
-D len
Maximum length of the data file (when re-creating data file when it is “full”).
Do a repair that tries to recover every possible row from the data file. Normally, this also finds a lot of garbage rows. Don't use this option unless you are desperate.
Overwrite old intermediate files (files with names like
)
instead of aborting.
tbl_name.TMD
For myisamchk, the option value is a bit-value that indicates which indexes to update. Each binary bit of the option value corresponds to a table index, where the first index is bit 0. An option value of 0 disables updates to all indexes, which can be used to get faster inserts. Deactivated indexes can be reactivated by using myisamchk -r.
Skip rows larger than the given length if myisamchk cannot allocate memory to hold them.
Uses the same technique as -r and
-n, but creates all the keys in parallel,
using different threads. This is beta-quality
code. Use at your own risk!
Achieve a faster repair by not modifying the data file. You can specify this option twice to force myisamchk to modify the original data file in case of duplicate keys.
Do a repair that can fix almost any problem except unique
keys that aren't unique (which is an extremely unlikely
error with MyISAM tables). If you want
to recover a table, this is the option to try first. You
should try --safe-recover only if
myisamchk reports that the table can't
be recovered using --recover. (In the
unlikely case that --recover fails, the
data file remains intact.)
If you have lots of memory, you should increase the value
of sort_buffer_size.
Do a repair using an old recovery method that reads
through all rows in order and updates all index trees
based on the rows found. This is an order of magnitude
slower than --recover, but can handle a
couple of very unlikely cases that
--recover cannot. This recovery method
also uses much less disk space than
--recover. Normally, you should repair
first with --recover, and then with
--safe-recover only if
--recover fails.
If you have lots of memory, you should increase the value
of key_buffer_size.
Specify the collation to use for sorting table indexes. The character set name is implied by the first part of the collation name.
Force myisamchk to use sorting to resolve the keys even if the temporary files would be very large.
Path of the directory to be used for storing temporary
files. If this is not set, myisamchk
uses the value of the TMPDIR
environment variable. tmpdir can be set
to a list of directory paths that are used successively in
round-robin fashion for creating temporary files. The
separator character between directory names is the colon
(‘:’) on Unix and the
semicolon (‘;’) on Windows,
NetWare, and OS/2.
Unpack a table that was packed with myisampack.

User Comments
This information doesn't cover what to do when myisamchk reports the following error:
myisamchk: error: '<table>' doesn't have a correct index definition. You need to recreate it before you can do a repair
This is what i used after I got the error:
3 rows in set (0.15 sec)"doesn't have a correct index definition. You need to recreate it before you can do a repair"
Login to command line mysql
mysql> CHECK TABLE stats;
mysql> REPAIR TABLE stats;
3 rows in set (0.22 sec)
Thanks to a google search I found this tip form Kevin W. Paulisse on http://support.discusware.com/forum/messages/7/14583.html?1037883255. "it appears that this error code is associated with a crash of the MySQL database, where the table (in this case, the search table) is marked as needing repair."
Now the table is up and running again, with all the data
You get the "***.MYD doesn't have a correct index definition" message when you run myisamchk on .MYD file. The doc says you can run it either with only the table name, or with .MYI file. e.g.
myisamchk mytab -- right
myisamchk mytab.MYI -- right
myisamchk myta.MYD -- wrong!
Either of the two right commands check the whole table, including mytab.MYD.
That's why mysql asks for an index file when you pass in a datafile.
Hope that helps.
Under the --keys-used=val option it should be noted that doing a myisamchk -r will not reactivate the keys until after a mysqladmin flush-tables has been executed.
Add your own comment.