Introduction

Recovering a table from .MYD, .MYI, and .frm files is a MyISAM-specific recovery task. The safe approach is to use a compatible MySQL environment, copy the table files into the correct database directory, then check and repair the table with MySQL tools such as CHECK TABLE, REPAIR TABLE, or myisamchk.

What These Files Mean

For MyISAM tables, MySQL stores each table as three files:

• '.frm for the table definition'
• '.MYD for the data rows'
• '.MYI for indexes'

That file layout is specific to MyISAM. If the original table used InnoDB, these files are not enough to reconstruct the table in the same way, and this recovery process does not apply.

Start With A Compatible Recovery Environment

The recovery host should match the original MySQL family and be as close as possible in version and platform. That reduces the risk of metadata mismatches and file-format differences.

Before touching anything:

• make a copy of the raw files
• verify the table was really MyISAM
• recover on a test machine first, not on production

Working from copies matters because repair operations can rewrite index or data files.

Basic Recovery Workflow

Create the target database on the recovery server first.

CREATE DATABASE recovered_db;

Then stop MySQL before copying files into the data directory if you plan to manipulate table files directly.

sudo systemctl stop mysqld

Copy the table files into the database directory, then make sure ownership matches the MySQL server user.

sudo cp table.frm table.MYD table.MYI /var/lib/mysql/recovered_db/
sudo chown mysql:mysql /var/lib/mysql/recovered_db/table.*

After that, start the server again.

sudo systemctl start mysqld

If the table opens, check it first before attempting repair.

CHECK TABLE recovered_db.table_name;
REPAIR TABLE recovered_db.table_name;

For MyISAM tables, REPAIR TABLE is the normal SQL-level repair tool.

Offline Repair With myisamchk

If SQL-level repair is not enough, use myisamchk while the server is stopped or while the table is guaranteed not to be in use.

sudo systemctl stop mysqld
myisamchk -r /var/lib/mysql/recovered_db/table.MYI
sudo systemctl start mysqld

The repair operates against the index file and may rebuild index structures. In more difficult cases, myisamchk also has extended modes, but the conservative first step is -r for recover.

When USE_FRM Helps

If the index file is damaged and MySQL must reconstruct index metadata from the table definition, a statement like this can help:

REPAIR TABLE recovered_db.table_name USE_FRM;

That option is specific to engines and table layouts where MySQL can rebuild from the .frm definition. It is useful only in the kinds of legacy MyISAM situations where these files are present.

Validate The Result

Recovery is not finished when the table becomes readable. Run row counts, sample queries, and any application-level consistency checks you have.

SELECT COUNT(*) FROM recovered_db.table_name;
SELECT * FROM recovered_db.table_name LIMIT 10;

If the table participates in application logic, verify foreign-key-like relationships in code as well, even though MyISAM itself does not enforce true foreign keys.

Common Pitfalls

The most common mistake is trying this process on InnoDB tables. The .MYD, .MYI, and .frm layout is a MyISAM pattern, not a general MySQL recovery recipe.

Another mistake is running myisamchk while mysqld is actively using the table. MySQL's documentation is clear that the server should not be using the table during that repair path.

It is also easy to ignore version compatibility. Even if file names look right, recovery is more reliable when the recovery server closely matches the original environment.

Summary

• '.frm, .MYD, and .MYI recovery applies to MyISAM tables.'
• Work on copies and use a compatible MySQL version when possible.
• Copy files into the correct database directory and fix ownership.
• Try CHECK TABLE and REPAIR TABLE first, then myisamchk offline if needed.
• Validate the recovered table with real queries before trusting the result.