Symptoms of corrupted tables include queries that abort
unexpectedly and observable errors such as these:

tbl_name.frm
is locked against change

Can't find file
tbl_name.MYI
(Errcode: nnn)

Unexpected end of file

Record file is crashed

Got error nnn from table handler

To get more information about the error, run
perrornnn, where
nnn is the error number. The
following example shows how to use perror to
find the meanings for the most common error numbers that
indicate a problem with a table:

Note that error 135 (no more room in record file) and error 136
(no more room in index file) are not errors that can be fixed by
a simple repair. In this case, you must use
ALTER TABLE to increase the
MAX_ROWS and
AVG_ROW_LENGTH table option values:

For the other errors, you must repair your tables.
myisamchk can usually detect and fix most
problems that occur.

The repair process involves up to four stages, described here.
Before you begin, you should change location to the database
directory and check the permissions of the table files. On Unix,
make sure that they are readable by the user that
mysqld runs as (and to you, because you need
to access the files you are checking). If it turns out you need
to modify files, they must also be writable by you.

If you are going to repair a table from the command line, you
must first stop the mysqld server. Note that
when you do mysqladmin shutdown on a remote
server, the mysqld server is still available
for a while after mysqladmin returns, until
all statement-processing has stopped and all index changes have
been flushed to disk.

You have to repair only those tables for which
myisamchk announces an error. For such
tables, proceed to Stage 2.

If you get unexpected errors when checking (such as out
of memory errors), or if myisamchk
crashes, go to Stage 3.

Stage 2: Easy safe repair

First, try myisamchk -r -q
tbl_name (-r
-q means “quick recovery mode”). This
attempts to repair the index file without touching the data
file. If the data file contains everything that it should and
the delete links point at the correct locations within the data
file, this should work, and the table is fixed. Start repairing
the next table. Otherwise, use the following procedure:

If you get unexpected errors when repairing (such as
out of memory errors), or if
myisamchk crashes, go to Stage 3.

Stage 3: Difficult repair

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 is necessary to
create a new index file. Do so as follows:

Move the data file to a safe place.

Use the table description file to create new (empty) data
and index files:

Copy the old data file back onto the newly created data
file. (Do not just move the old file back onto the new file.
You want to retain a copy in case something goes wrong.)

Important

If you are using replication, you should stop it prior to
performing the above procedure, since it involves file system
operations, and these are not logged by MySQL.

Go back to Stage 2. myisamchk -r -q should
work. (This should not be an endless loop.)

You can also use the REPAIR TABLE
tbl_name USE_FRM SQL
statement, which performs the whole procedure automatically.
There is also no possibility of unwanted interaction between a
utility and the server, because the server does all the work
when you use REPAIR TABLE. See
Section 13.7.2.6, “REPAIR TABLE Syntax”.

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 is not
changed after the table is created:

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.

If you do not 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, and 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.

I landed on this webpage because of Error 145 ("Table was marked as crashed and should be repaired"). I was able to 'fix' it by just using "REPAIR TABLE" (12.4.2.6). According to that doc, REPAIR TABLE is the equivalent of "myisamchk --recover (-r)".

In some circumstances, REPAIR Table & myisamchk – repair with r option are not able to fix corruption in tables. In that situation you can get help from any third party mysql repair utility that meets your requirement and budget.Some top mysql repair software are:Stellar Phoenix Database Recovery for MySQLRecovery for MySQLNote: First try free download demo version of any software before buy.

MySQL automatically tries & checks to repair MyISAM tables if they are marked as 'Record-file is crashed',‘crashed’ 'No more room in index file' or ‘not closed properly’. MyISAM table damage and MySQL generates a lot of errors such as ‘Warning: Multiple instances of MySQL’, ‘Warning: Checking table….'‘Warning: Repairing table…’and needs to be repaired. For more info http://exchangeserver.tumblr.com/post/27540224026/repairs-mysql-server-database