Fix MySQL 'Table Marked as Crashed' Error Fast

You're trying to run a query on a MySQL or MariaDB table, and you get back something like Table 'your_table' is marked as crashed and should be repaired. This is error code 1194. It usually happens after a server crash, power outage, or disk full event. I had a client last month whose entire CRM went down because a hard drive ran out of space mid-write. The table won't let you read from it, write to it, or even see its structure properly.

What causes this?

MySQL and MariaDB use something called MyISAM or Aria storage engines for some system tables (like the MySQL user database) or custom tables. These engines are fast but fragile. If the server crashes while writing to the table, the index file gets out of sync with the data file. The next time you try to access it, the engine marks it as crashed. It's like a file system corruption, but just for that one table. InnoDB tables handle crashes better, but they can still get corrupted if the disk writes fail.

The fix: two methods that work

Here's the good news: MyISAM tables have a built-in repair tool. You don't need to restore from a backup, unless the hardware is dying. Try these steps in order.

Method 1: REPAIR TABLE SQL command (easiest)

1. Connect to your MySQL server. Using command line: mysql -u root -p
2. Select the database with the crashed table: USE your_database_name;
3. Repair the table: REPAIR TABLE your_table_name;
4. If that fails, try more aggressive: REPAIR TABLE your_table_name USE_FRM;

This rebuilds the index file from the data. It usually works. But if the data file itself is corrupted, you might need the next method.

Method 2: mysqlcheck command line tool (for sysadmins)

1. Open a terminal or command prompt as admin or root.
2. Run: mysqlcheck -u root -p --repair your_database_name your_table_name
3. For all tables in a database: mysqlcheck -u root -p --repair --databases your_database_name
4. For all databases: mysqlcheck -u root -p --repair --all-databases

The --repair flag does the same thing as REPAIR TABLE internally. You can also add --auto-repair to automatically fix all crashed tables.

What if the repair fails?

Sometimes the data file is too damaged. Before you panic, try these extra steps:

• Check disk space. A full disk can cause this. Free up space and try again. df -h on Linux.
• Check table permissions. The MySQL user must have write access to the database directory. On Linux, that's usually /var/lib/mysql/your_database/. Check ownership: chown mysql:mysql /var/lib/mysql/your_database/*
• Restore from backup. If the repair says success but you still can't read data, your backup is your friend. The table's data might be gone. This is why you run backups.

Preventing this in the future

You can't stop power outages, but you can make your tables more resilient. Switch important tables to InnoDB (ALTER TABLE your_table ENGINE=InnoDB;). InnoDB handles crashes way better. For system tables that must stay MyISAM, set myisam_recover_options=FORCE in your MySQL config file (my.cnf on Linux, my.ini on Windows). This auto-repairs crashed MyISAM tables on server start.

If nothing works

You're down to the nuclear option: re-create the table. Use SHOW CREATE TABLE your_table_name; from a working backup or from memory. Create a new table with that structure, then try to copy data from the crashed table using INSERT ... SELECT with IGNORE to skip bad rows. It's messy but sometimes the only way. I've done this for a small table with 500 rows. Took 15 minutes.

"If the table is in the MySQL system database (like mysql.user), you can't just drop and recreate it. You risk losing user accounts. Fix it carefully using mysql_upgrade."

You'll be fine. 90% of the time REPAIR TABLE works. If not, you know what to check next.