How to Repair MySQL Database Safely (2026 Step-by-Step)

Quick Answer (as of July 2026): To repair a corrupted MySQL database, back it up first — a raw copy of the data directory or a mysqldump — then match the repair to the storage engine. MyISAM tables recover with REPAIR TABLE, mysqlcheck or myisamchk. InnoDB tables need innodb_force_recovery plus a dump and reload. WordPress sites can start with the built-in repair tool. Never repair without a backup.

That is how to repair MySQL database tables in the order a working host would do it — and the order matters more than any single command.

Our team resolves 20-30 client issues every day, and a crashed table after an unexpected reboot is one of the calls we get most often at Hostaccent. This guide is the same sequence our engineers run when a ticket comes in at 2am, written out so you can run it yourself. Nothing is held back, and nothing here is scarier than it needs to be.

Deep breath. Corrupted almost never means gone.

What "MySQL Table Is Marked as Crashed" Actually Means

A crashed table means the index file no longer matches the data file — not that your data has been deleted. MySQL noticed the mismatch, flagged the table, and refused to serve it rather than hand you wrong rows.

The classic message looks like this:

bashCopy
Table './mydb/wp_options' is marked as crashed and should be repaired

The mysql table is marked as crashed error is a MyISAM signature. MyISAM splits every table into three files on disk: .frm (structure), .MYD (the data), and .MYI (the index). If MySQL is killed mid-write, the .MYI gets a "not cleanly closed" header flag while the .MYD sits there intact. Your rows are usually fine. The map to them isn't.

InnoDB behaves differently. It has a transaction log and repairs itself on startup most of the time. When InnoDB does break, you get pages that fail checksum validation and a server that refuses to start — a bigger problem, with a different fix. Both are covered below.

A wp_options crashed error hits hardest because WordPress reads that table on literally every page load. One flagged index and the whole site returns a database connection error, even though 99% of your content is untouched.

Insider Insight: Check the storage engine before you pick a repair command. Run SHOW TABLE STATUS FROM mydb; and read the Engine column. Running myisamchk against an InnoDB table does nothing useful and wastes the twenty minutes you don't have. MySQL's official documentation on storage engines spells out the differences, and the MariaDB project documents the same behaviour for MariaDB-based servers.

Why Databases Corrupt: Causes Ranked by What We Actually See

Corruption is almost always a symptom, not a disease. Repair the table, ignore the cause, and you'll be back here next month.

Ranked by real frequency across the servers we run:

1. Unclean shutdown. Power loss, a hard reboot, a kill -9 on mysqld, or the Linux OOM killer terminating MySQL to save the box. This is the number one cause by a wide margin. If your server is memory-starved, the kernel will keep doing this — diagnosing why your VPS runs out of RAM fixes the root cause the repair command can't touch.

2. Disk full or inodes exhausted. MySQL writes an index update, the write returns "no space left on device", and the table is left half-written. We have handled disk-full emergencies where every site on a server went down at once, and the databases came back cleanly the moment space was freed and tables were repaired.

3. Resource limits on shared hosting. A process gets throttled or killed mid-query. If your control panel keeps flagging limits, shared hosting resource limit exceeded errors explains what's being capped and why.

4. Failing storage or filesystem errors. Rarer on modern NVMe SSD arrays than on old spinning disks, but real. Check dmesg for I/O errors before blaming MySQL.

5. Version mismatches after a botched migration. Copying raw /var/lib/mysql files between different MySQL or MariaDB versions works right up until it doesn't.

From the Ticket Queue: WordPress issues 30% · brute-force and malware 25% · Linux server issues 25% · SSL problems 20% — that's the share of monthly Hostaccent support tickets. Database crashes sit inside the first and third buckets, and they cluster after outages, never at random.

Notice what isn't on the list: "MySQL is unreliable." In our experience, the database is usually the messenger.

Step Zero: Back Up Before You Repair Anything

Repair commands rewrite files in place. If a repair goes wrong halfway through, there is no undo — and that is the single way this incident turns from an inconvenience into a disaster.

Take a copy first. Always. Even at 2am. Even when the site is down and someone is messaging you.

If MySQL is still running, take a logical dump:

bashCopy
mysqldump -u root -p --single-transaction --routines mydb > /root/mydb-backup.sql

If a crashed table blocks the dump, skip it and dump the rest, then handle the broken one separately:

bashCopy
mysqldump -u root -p mydb --ignore-table=mydb.wp_options > /root/mydb-partial.sql

If MySQL won't start, stop it fully and copy the raw files:

bashCopy
systemctl stop mysql
cp -a /var/lib/mysql /root/mysql-datadir-backup

The -a matters — it preserves ownership and timestamps. A copy owned by root that MySQL can't read is not a backup.

On shared hosting with no SSH, export the database through phpMyAdmin (Export → Custom → SQL) or use your control panel's backup wizard. cPanel's documentation covers the backup interface if you're unsure which button does what.

Pro Tip: Copy the backup off the server before you start. A backup sitting on the same disk that just filled up or started throwing I/O errors is not insurance — it's optimism. Even a quick scp to your laptop counts. If you'd rather this happened automatically forever, automating Linux VPS backups with rsync and cron takes about twenty minutes to set up once.

Across the 4,000+ sites we've migrated since 2012, the step people most often skip is this one — and it's the only step that's genuinely unrecoverable when skipped.

How to Repair MySQL Database Tables: Four Methods, Safest First

Work down this list. Stop at the first method that works. Each one is more invasive than the last, so there is no prize for starting at the bottom.

Method 1 — WordPress database repair (built-in tool)

If this is a WordPress site, start here. It's the safest option and needs no SSH.

Add this line to wp-config.php, above the "stop editing" comment:

phpCopy
define( 'WP_ALLOW_REPAIR', true );

Then visit https://yoursite.com/wp-admin/maint/repair.php and choose Repair Database. WordPress runs REPAIR TABLE against every table it owns and reports each result.

The WordPress database repair tool needs no login — which is exactly why you must remove that line from wp-config.php the moment you're done. Leaving it enabled is an open door, and it's the kind of thing that shows up later as a hacked-site ticket. The WordPress documentation says the same thing, and it's worth taking literally.

Success looks like: wp_options: Successfully repaired the table.

Method 2 — phpMyAdmin or your control panel

No SSH, not WordPress? Open phpMyAdmin, select the database, tick the affected tables (or "Check all"), and pick Repair table from the dropdown at the bottom.

This runs the same SQL as Method 3 — it just wraps it in a UI. It works on MyISAM. It will politely do nothing for InnoDB, which is not a bug.

Method 3 — mysqlcheck from SSH

The command-line version, and the one to reach for when several tables are flagged at once:

bashCopy
mysqlcheck -u root -p --auto-repair --check --optimize mydb

Or every database on the server:

bashCopy
mysqlcheck -u root -p --auto-repair --all-databases

To repair a single table from inside the MySQL shell:

sqlCopy
REPAIR TABLE wp_options;

Honest caveat, because most guides gloss over it: REPAIR TABLE can drop rows it can't reconstruct, and it reports how many. Read the output. "Number of rows changed from 44,182 to 44,180" means you lost two rows — usually harmless in wp_postmeta, less harmless in an orders table.

If the standard repair fails, one step up:

sqlCopy
REPAIR TABLE wp_options USE_FRM;

USE_FRM rebuilds the index from the table definition instead of the damaged index file. Only for MyISAM, and only after the normal repair has failed — it discards the existing index entirely.

Method 4 — myisamchk repair table (offline, last resort)

myisamchk works directly on the files, which is why it's powerful and why it's dangerous. MySQL must be stopped, or you will corrupt the table you're trying to save.

bashCopy
systemctl stop mysql
cd /var/lib/mysql/mydb
myisamchk --recover --quick wp_options.MYI

If --quick fails, escalate:

bashCopy
myisamchk --recover wp_options.MYI
myisamchk --safe-recover wp_options.MYI    ## slower, older algorithm, recovers more

Then fix ownership before starting the server again — this is the step people forget, and the server won't come up without it:

bashCopy
chown -R mysql:mysql /var/lib/mysql/mydb
systemctl start mysql

The myisamchk repair table route is what we use when a table is too broken for SQL-level repair to even parse. On one restore after a hardware failure, we found the index file rebuilt clean with --safe-recover after --quick had refused twice. It took eleven minutes on a 2 GB table. Patience beats panic.

Live site and no time to experiment? Our engineers fix crashed and corrupted MySQL tables for a small one-time fee, and you'll see the exact quote before anyone touches a single file. Hosted with Hostaccent? Then issues like this are simply covered by support — free, no ticket gymnastics. Have an engineer fix it

When it's InnoDB: innodb_force_recovery

InnoDB won't repair with any command above. If mysqld refuses to start and the error log mentions page checksum failures or an assertion, add this to /etc/mysql/my.cnf under [mysqld]:

bashCopy
innodb_force_recovery = 1

Start MySQL, immediately mysqldump everything you can, then remove the setting, reinstall a clean database, and reload the dump. Climb the value 1 → 2 → 3 only if the server still won't start. Levels 4 and above can discard data permanently. Stop at 3 unless you have a copy of the datadir sitting somewhere safe — and you do, because you did Step Zero.

How to Confirm the Repair Worked and Stop It Recurring

Confirm first. A quiet server is not a fixed server.

Run the check without the repair flag:

bashCopy
mysqlcheck -u root -p --check mydb

Every table should return OK. Then load the actual site — front end and /wp-admin — and watch the MySQL error log for thirty seconds:

bashCopy
tail -f /var/log/mysql/error.log

Now the part that keeps you from doing this again. Call it the 60-second crash triage: space, memory, engine.

• Space: df -h and df -i. Under 10% free on either is a crash waiting to happen.
• Memory: grep -i 'killed process' /var/log/syslog. If the OOM killer has been taking out mysqld, no amount of repairing helps.
• Engine: if you're still on MyISAM in 2026, convert. ALTER TABLE wp_options ENGINE=InnoDB; InnoDB's crash recovery means an unclean shutdown becomes a two-second rollback instead of a repair session. This one change removes most of the risk this article exists for.

Two more habits worth building: keep offsite backups you have actually restored from at least once, and lock the box down properly — a Linux VPS security baseline for Ubuntu 24.04 takes half an hour and prevents the malware-driven database damage that makes up a real slice of our ticket queue. If the site feels sluggish once it's back, fixing high TTFB in WordPress is the natural next read — a bloated wp_options table is often behind both problems.

Pro Tip: After any repair, check for autoloaded bloat: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'; Anything over ~1 MB is loading on every single request. Cleaning it makes the table smaller, faster, and statistically less likely to crash again.

Your Next Step: Fixed It, or Still Stuck?

Path A — the table's repaired. Take one thing from tonight: convert MyISAM to InnoDB and put a real backup schedule in place. Then the honest observation, which you're free to ignore: knowing how to repair MySQL database tables is a genuinely useful skill, but on a well-managed host it should be support's job at 2am, not yours. That's the arrangement Hostaccent runs on — a UK-registered company (Companies House 11431799), trading since 2012 and UK-incorporated in 2018, with 10,000+ sites launched and real engineers on the other end of the ticket. If you want that setup, start on the Economy plan — Economy — $1.99/mo, which renews at $1.99/mo, with a 99.9% uptime guarantee, a 30-day money-back guarantee, and your domain and hosting on one dashboard with a single renewal date. Skip it if your database is 6 GB and query-heavy — shared hosting is the wrong home for that, and Standard or a VPS fits better. And don't buy a plan to fix tonight's crash; fix the crash, then decide.

Path B — still stuck. Open a ticket with our engineers. Small one-time fee, exact quote before any work starts, and it's free for Hostaccent hosting clients, because at that point it's just support.

Frequently Asked Questions About MySQL Database Repair

Will repairing a MySQL table delete my data?

Usually no. REPAIR TABLE rebuilds the index from the existing data file and keeps your rows. It can drop rows it cannot reconstruct, and it tells you how many in its output. That's exactly why you take a mysqldump or a raw copy of the data directory before running any repair command.

How to repair MySQL database tables from the command line?

Use mysqlcheck -u root -p --auto-repair --check mydb for MyISAM tables while MySQL is running. If that fails, stop MySQL and run myisamchk --recover --quick /var/lib/mysql/mydb/table.MYI, then chown -R mysql:mysql the directory before restarting. InnoDB needs innodb_force_recovery and a dump-and-reload instead.

Why does wp_options crash more than other tables?

WordPress writes to wp_options constantly — transients, cron entries, plugin settings — and reads it on every request. More writes means a bigger window for an unclean shutdown to catch it mid-update. It's not that the table is fragile; it's simply the busiest table in the database.

Can I repair a database from cPanel without SSH?

Yes. Use phpMyAdmin, select the database, tick the affected tables and choose "Repair table" from the dropdown. It runs the same SQL as the command line. It works for MyISAM only. For InnoDB corruption you'll need server-level access, which on shared hosting means your host's support team.

Does InnoDB really not need repairing?

InnoDB repairs itself on startup in most cases using its redo log, which is why it's the right default in 2026. Real InnoDB corruption is rarer but more serious — it needs innodb_force_recovery plus a full dump and reload, not a repair command. Converting MyISAM tables to InnoDB removes most crash risk.

What if the repair works but the site is still down?

Then the database was a symptom, not the cause. Check disk space with df -h, look for OOM kills in syslog, and confirm MySQL is actually accepting connections. If MySQL is healthy and the site still errors, the credentials in wp-config.php or a PHP-FPM pool are the next suspects — Hostaccent's engineers see that exact sequence several times a month.