How to Fix MySQL Error 1194: Table Is Marked as Crashed

ERROR 1194 (HY000): Table '<table_name>' is marked as crashed and should be repaired is raised when MySQL attempts to read from or write to a MyISAM table whose internal state flags indicate it was not closed cleanly or has structural corruption. The error symbol is ER_CRASHED_ON_USAGE.

Impact

Any query touching the affected table — SELECT, INSERT, UPDATE, DELETE — immediately fails with this error until the table is repaired. The table is effectively inaccessible; MySQL will not attempt to read or write data to prevent further corruption. If your application does not handle this error explicitly, it typically surfaces as a generic database exception: Django raises OperationalError, ActiveRecord raises ActiveRecord::StatementInvalid, and JDBC drivers throw SQLException with SQLState HY000.

This error is specific to the MyISAM storage engine, which does not support crash-safe recovery. InnoDB tables do not produce error 1194 because InnoDB uses a redo log and automatic crash recovery at startup.

Common Causes

Unclean server shutdown — if mysqld is killed or the host crashes while a MyISAM write is in progress, the table's open-count flag is left non-zero, marking it as crashed on next access.
OS or hardware I/O error — a disk write failure, a full filesystem, or a RAID issue can corrupt the .MYD (data) or .MYI (index) files that back a MyISAM table.
Running out of disk space mid-write — MyISAM tables are file-backed; a full disk during an INSERT or bulk load leaves the table in a partially written state.
Concurrent access without proper locking — direct filesystem-level operations (copying files, running rsync) on live MyISAM files while MySQL is running can corrupt the index file.
MySQL bug or version-specific issue — certain older MySQL 5.x releases had known bugs that could mark tables as crashed under high write concurrency; upgrading resolved them.

Troubleshooting and Resolution Steps

Identify the crashed table. The table name appears in the error message itself. You can also inspect all MyISAM tables for corruption using CHECK TABLE:
```
CHECK TABLE your_table_name;
```
Look for rows where Msg_type is error or warning in the result set.
Repair the table with REPAIR TABLE. This is the simplest in-SQL approach:
```
REPAIR TABLE your_table_name;
```
MySQL rebuilds the index file and resets the crashed flag. The Msg_text column in the result will show OK on success. For tables with severe data corruption, add EXTENDED to do a row-by-row repair:
```
REPAIR TABLE your_table_name EXTENDED;
```

Repair from the shell using mysqlcheck. This is useful for scripting or repairing multiple tables at once:

# Repair a single table
mysqlcheck --repair --user=root --password your_database your_table_name

# Repair all MyISAM tables in a database
mysqlcheck --repair --user=root --password your_database

# Check and repair all databases
mysqlcheck --all-databases --auto-repair --user=root --password

Repair at the file level using myisamchk. If the server is under heavy load or REPAIR TABLE fails, stop MySQL and run myisamchk directly against the table files:
```
sudo systemctl stop mysql
myisamchk --recover /var/lib/mysql/your_database/your_table_name.MYI
sudo systemctl start mysql
```
Use --safe-recover if the standard recover fails; it is slower but handles more severe corruption.
Restore from backup if repair fails. If all repair attempts return errors, the data file may be too damaged to recover. Restore from a known-good backup and replay any binary log events since the backup to minimize data loss.
Consider migrating to InnoDB. If crashes are recurring, the long-term fix is to convert the table to InnoDB, which recovers automatically after crashes:
```
ALTER TABLE your_table_name ENGINE=InnoDB;
```
Verify there are no FULLTEXT indexes that rely on MyISAM before converting (MySQL 5.5 and earlier did not support InnoDB full-text indexes; MySQL 5.6+ does).

Additional Information

Related error codes: Error 1195 (ER_CRASHED_ON_REPAIR) is raised when a REPAIR TABLE attempt itself fails, indicating deeper corruption that may require file-level recovery or restore from backup.
MyISAM-only: InnoDB, MEMORY, ARCHIVE, and other storage engines do not raise error 1194. If you see it on an InnoDB table name, the table was likely using MyISAM at the time of the crash.
myisam_recover_options server variable: Setting myisam_recover_options=BACKUP,FORCE in my.cnf causes MySQL to attempt automatic MyISAM recovery at startup and on open, which can prevent error 1194 from surfacing at all in many crash scenarios.
Replication note: On a replica, a crashed MyISAM table will cause replication SQL thread errors. Run REPAIR TABLE on the replica before resuming replication with START REPLICA.
MySQL 8.0: MyISAM is still supported but discouraged. The default storage engine has been InnoDB since MySQL 5.5. New tables created without an explicit ENGINE= clause use InnoDB and will never encounter error 1194.

Frequently Asked Questions

Why does this only happen with MyISAM and not InnoDB? InnoDB uses a write-ahead redo log and performs automatic crash recovery at startup, rolling back incomplete transactions and replaying committed ones. MyISAM has no transaction log; it relies on a simple open-count flag in the index file. If MySQL shuts down without decrementing that counter, the file is considered uncleanly closed and is flagged as crashed.

Can I prevent this error without switching to InnoDB? Yes. Set myisam_recover_options = BACKUP,FORCE in your my.cnf (under [mysqld]). This instructs MySQL to automatically repair crashed MyISAM tables when they are first opened, writing a backup of the original data file before repair. This reduces but does not eliminate the risk — severe corruption still requires manual intervention.

Will REPAIR TABLE cause data loss? It can. REPAIR TABLE rebuilds the index from the data file; if the data file (.MYD) itself is corrupt, some rows may be unrecoverable. The EXTENDED option performs a more thorough rebuild but is not a guarantee. Always take a filesystem-level backup of the .MYD and .MYI files before attempting repair on important tables.

How do I check all MyISAM tables across all databases for corruption? Use mysqlcheck with the --all-databases and --check flags:

mysqlcheck --all-databases --check --user=root --password

Tables with issues will show a status of Table is already up to date (healthy) or an error/warning line (needs repair). Pipe the output through grep -v "OK" to surface only the problem tables.