You should reach this stage only if the first 16KB block in the index file is destroyed or contains incorrect information, or if the index file is missing. In this case, it’s necessary to create a new index file. Do so as follows:
1. Move the data file to some safe place.
2. Use the table description file to create new (empty) data and index files:
shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit
If your version of MySQL doesn’t have TRUNCATE TABLE, use DELETE FROM tbl_name instead.
3. Copy the old data file back onto the newly created data file. (Don’t just move the old file back onto the new file; you want to retain a copy in case something goes wrong.)
Go back to Stage 2. myisamchk -r -q should work. (This shouldn’t be an endless loop.)
As of MySQL 4.0.2, you can also use REPAIR TABLE tbl_name USE_FRM, which performs the whole procedure automatically.
Stage 4: Very difficult repair
You should reach this stage only if the .frm description file has also crashed. That should never happen, because the description file isn’t changed after the table is created:
1. Restore the description file from a backup and go back to Stage 3. You can also restore the index file and go back to Stage 2. In the latter case, you should start with myisamchk -r.
2. If you don’t have a backup but know exactly how the table was created, create a copy of the table in another database. Remove the new data file, then move the .frm description and .MYI index files from the other database to your crashed database. This gives you new description and index files, but leaves the .MYD data file alone. Go back to Stage 2 and attempt to reconstruct the index file.