🚨 MySQL Error Guide: 'ERROR 1194 (HY000)' Table Is Marked as Crashed and Should Be Repaired (MyISAM)

Exact Error Message

ERROR 1194 (HY000): Table 'sessions' is marked as crashed and should be repaired

A related variant indicates an automatic repair attempt failed or is required:

ERROR 1034 (HY000): Incorrect key file for table 'sessions'; try to repair it

What the Error Means

ERROR 1194 is specific to the MyISAM storage engine (and its variants like Aria). MyISAM stores a per-table “open count” flag in the index (.MYI) file. When the table is opened, the flag is incremented; when cleanly closed, it is decremented. If mysqld crashes, the host loses power, or the process is killed while a table is open, the flag is left set and MyISAM marks the table as crashed. Because MyISAM is not crash-safe and not transactional, an interrupted write can also leave the index and data (.MYD) files inconsistent.

Until the table is repaired, MySQL refuses most operations on it to prevent serving corrupt data. The good news is MyISAM corruption is usually repairable with REPAIR TABLE or myisamchk.

Common Causes

• mysqld crashed or the server lost power while the table was open.
• The host ran out of disk space mid-write, leaving an incomplete index or data file.
• The process was hard-killed (kill -9, OOM killer) without a clean shutdown.
• Concurrent writes exceeded MyISAM’s locking guarantees during an abrupt stop.
• A hardware/filesystem fault corrupted the .MYI or .MYD file.
• Copying MyISAM files at the filesystem level while the server had them open.

How to Reproduce the Error

Simulate corruption is destructive, so the safe demonstration is to query an already-flagged table. After an unclean shutdown, the first access surfaces the error:

SELECT COUNT(*) FROM sessions;

ERROR 1194 (HY000): Table 'sessions' is marked as crashed and should be repaired

The flag set during the crash blocks the read until a repair clears it.

Diagnostic Commands

Check the table’s engine and status (read-only):

mysql -e "SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='appdb' AND TABLE_NAME='sessions';"
mysql -e "CHECK TABLE appdb.sessions;"

CHECK TABLE reports the corruption without modifying data:

+------------------+-------+----------+----------------------------------------+
| Table            | Op    | Msg_type | Msg_text                               |
+------------------+-------+----------+----------------------------------------+
| appdb.sessions   | check | warning  | Table is marked as crashed             |
| appdb.sessions   | check | error    | Found 12043 keys of 12100              |
+------------------+-------+----------+----------------------------------------+

Look at the error log and disk space, since a full disk is a frequent cause:

journalctl -u mysql --since "2 hours ago" --no-pager | grep -i "marked as crashed"
df -h /var/lib/mysql

Confirm there is free space before repairing, because repair needs room for a temporary copy.

Step-by-Step Resolution

1. Stop application writes to the affected table while you repair, to avoid racing the repair.
2. Run an online repair via SQL (server stays up):

REPAIR TABLE appdb.sessions;

For deeper damage, use REPAIR TABLE appdb.sessions EXTENDED; which rebuilds the index more thoroughly.

3. If the index is severely damaged, use REPAIR TABLE appdb.sessions USE_FRM; to rebuild from the table definition (last resort — may lose rows).
4. If the server cannot start or the table cannot be opened online, repair offline with myisamchk while mysqld is stopped (never run it on a live, running server’s files):

sudo systemctl stop mysql
sudo myisamchk --recover /var/lib/mysql/appdb/sessions.MYI
sudo systemctl start mysql

5. Re-run CHECK TABLE to confirm the table reports OK.
6. Restore from backup any rows the repair could not recover, comparing counts against your last known-good backup.

Prevention and Best Practices

• Migrate MyISAM tables to InnoDB, which is crash-safe and transactional: ALTER TABLE sessions ENGINE = InnoDB;. This eliminates ERROR 1194 entirely for those tables.
• If you must keep MyISAM, enable myisam-recover-options = BACKUP,FORCE so MySQL auto-repairs flagged tables at open time.
• Monitor disk space and alert before /var/lib/mysql fills, since a full disk is a leading cause of MyISAM corruption.
• Always shut down mysqld cleanly (systemctl stop mysql); avoid kill -9 and configure the OOM killer to spare the database.
• Keep regular, tested backups so unrecoverable corruption has a fallback.
• Never copy or move MyISAM .MYD/.MYI files while the server has the table open.

Related Errors

• ERROR 1034 (HY000): Incorrect key file for table — index file inconsistency, often repaired the same way.
• ERROR 1016 (HY000): Can't open file — the table files are missing or unreadable.
• ERROR 145: Table was marked as crashed and last (automatic?) repair failed — an auto-repair attempt already failed; manual repair needed.
• InnoDB equivalents like ERROR 1146 or Page corruption are handled differently (InnoDB recovery, not myisamchk).

Frequently Asked Questions

Will REPAIR TABLE lose data? Usually no for ordinary corruption. EXTENDED and USE_FRM repairs can drop unrecoverable rows; compare row counts to a backup afterward.

Can I avoid this entirely? Yes — convert the tables to InnoDB. MyISAM’s lack of crash safety is the root cause of ERROR 1194.

Why did it happen after a clean reboot? If the database did not shut down cleanly before the reboot (timeout, kill), the open flag was left set even though the OS rebooted normally.

Can I run myisamchk while MySQL is running? No. Running myisamchk against files of a live server can corrupt them further. Use online REPAIR TABLE, or stop mysqld first.

Does myisam-recover-options fix it automatically? With BACKUP,FORCE set, MySQL attempts repair when it next opens a flagged table, keeping a backup of the original. It is a strong safety net for MyISAM workloads. For more, see MySQL guides.