myisamchk supports the following options for
        table repair operations (operations performed when an option
        such as --recover or
        --safe-recover is given):
      
            
            
            --backup,
            -B
          
            Make a backup of the .MYD file as
            file_name-time.BAK
The directory where character sets are installed. See Section 9.6, “Character Set Configuration”.
Correct the checksum information for the table.
            
            
            --data-file-length=,
            len-D 
          len
The maximum length of the data file (when re-creating data file when it is “full”).
            
            
            --extend-check,
            -e
          
Do a repair that tries to recover every possible row from the data file. Normally, this also finds a lot of garbage rows. Do not use this option unless you are desperate.
For a description of the output format, see Section 4.6.2.5, “myisamchk Table Information”.
            
            
            --force,
            -f
          
            Overwrite old intermediate files (files with names like
            )
            instead of aborting.
          tbl_name.TMD
            
            
            --keys-used=,
            val-k 
          val
            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. For
            isamchk, the option value indicates that
            only the first val of the table
            indexes should be updated. In either case, 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 or
            (isamchk -r).
          
            
            
            --no-symlinks,
            -l
          
Do not follow symbolic links. Normally myisamchk repairs the table that a symlink points to. This option does not exist as of MySQL 4.0 because versions from 4.0 on do not remove symlinks during repair operations.
Skip rows larger than the given length if myisamchk cannot allocate memory to hold them. This option was added in MySQL 4.1.1.
            Uses the same technique as -r and
            -n, but creates all the keys in parallel,
            using different threads. This option was added in MySQL
            4.0.2. This is beta-quality code; use at your own
            risk!.
          
            
            
            --quick,
            -q
          
Achieve a faster repair by modifying only the index file, not the data file. You can specify this option twice to force myisamchk to modify the original data file in case of duplicate keys.
            
            
            --recover,
            -r
          
            Do a repair that can fix almost any problem except unique
            keys that are not unique (which is an extremely unlikely
            error with ISAM/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 cannot
            be recovered by --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.
          
            
            
            --safe-recover,
            -o
          
            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 using
            --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.
          
            Change the character set used by the table indexes. This
            option was replaced by
            --set-collation in MySQL
            4.1.1.
          
Specify the collation to use for sorting table indexes. The character set name is implied by the first part of the collation name. This option was added in MySQL 4.1.11.
            
            
            --sort-recover,
            -n
          
Force myisamchk to use sorting to resolve the keys even if the temporary files should be very large.
            
            
            --tmpdir=,
            path-t 
          path
            The 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. Starting from MySQL 4.1,
            --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 should be colon
            (“:”) on Unix and semicolon
            (“;”) on Windows, NetWare,
            and OS/2.
          
            
            
            --unpack,
            -u
          
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
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.
If you're trying to recover a HUGE table (10-100 million or more records) for which the .MYI file has become lost, here's one way to do it more quickly:
1. Run REPAIR TABLE ... USE_FRM, but kill it as soon as the .MYI is created
2. Stop any running copy of mysqld
3. Run myisamchk using one of the recover options
If you're dealing with the error:
Incorrect key file for table '[...].MYI'; try to repair it
After having run out of space on disk, make sure you have the following:
1. Enough free space left on the machine
2. Run the repair: myisamchk -r [...].MYI
3. Restart mysqld (this could/should be done before the repair and, in my case, was needed so that the mysqld "knew" it had more free space to work)
Humberto Silva
Add your own comment.