How to Repair a Corrupted MySQL Table (cPanel, CLI & phpMyAdmin)

Overview

MySQL table corruption is one of those problems that hits without warning. One minute your site’s fine, the next you’re staring at a 500 error or a WordPress database connection failure. MySQL repair is the fix — but how you do it depends on your storage engine, your access level, and how bad the damage actually is.

Corruption usually happens after a server crash, a forced shutdown during a write operation, or running out of disk space mid-transaction. MyISAM tables are especially vulnerable because they don’t support crash recovery. InnoDB handles it better with its transaction log, but it’s not immune, particularly if ibdata1 gets involved.

This article covers how to identify which tables are corrupted, repair them using multiple methods, and avoid the same problem coming back. Whether you’re on shared hosting with cPanel, a VPS SSD Hosting plan, or a dedicated server with root access, there’s a path here for you.

Prerequisites

• MySQL 5.7+ or MariaDB 10.3+ (commands work on both; noted where they differ)
• SSH access with sudo or root privileges or access to cPanel/phpMyAdmin
• The name of the affected database and table (check your CMS error logs if unsure)
• A recent database backup — do this before touching anything
• Enough free disk space to write temporary repair files (at least equal to the table’s .MYD file size for MyISAM)

Step 1: Identify the Corrupted Table

Before you repair anything, confirm which table is actually broken. Don’t guess based on the CMS error alone — it’s often misleading.

Option A: Check MySQL error logs

On most Linux servers, the MySQL error log is here:

sudo tail -n 100 /var/log/mysql/error.log
# or on cPanel servers:
sudo tail -n 100 /var/lib/mysql/$(hostname).err

Look for lines containing Incorrect key file, Table './dbname/tablename' is marked as crashed, or Got error 127. That’ll tell you the exact table.

Option B: Run mysqlcheck to scan the whole database

mysqlcheck -u root -p --check your_database_name

Replace your_database_name with your actual database. You’ll be prompted for the MySQL root password. Any table showing error or crashed in the output needs attention.

To scan all databases at once:

mysqlcheck -u root -p --check --all-databases

Step 2: Take a Backup First

⚠ Warning: Repair operations modify your table files directly. If the repair goes wrong on a severely damaged table, you could lose data. Back up now.

mysqldump -u root -p your_database_name > /root/db_backup_$(date +%F).sql

If the table is so corrupted that mysqldump fails, skip to the InnoDB recovery section below.

Step 3: Repair the Table

Which method you use depends on your storage engine. If you don’t know which engine your table uses, run this first:

SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database_name';

Method 1: REPAIR TABLE (MyISAM only — fastest for cPanel users)

Log in to MySQL and run the repair command directly:

mysql -u root -p

-- Once inside the MySQL prompt:
USE your_database_name;
REPAIR TABLE your_table_name;
EXIT;

You’ll see output with a status column. If it says OK, you’re done. If it says error, the damage is more serious and you’ll need myisamchk (Method 2).

📝 Note: REPAIR TABLE only works on MyISAM and ARCHIVE storage engines. Running it on an InnoDB table will return a note saying it doesn’t apply — it won’t break anything, but it won’t fix anything either.

Method 2: myisamchk (MyISAM, deeper repair)

For tables that REPAIR TABLE couldn’t fix, use the lower-level myisamchk tool. You need to stop MySQL first or the tool can’t get an exclusive lock on the files.

⚠ Warning: Stopping MySQL will take down any site using that database server. Do this during a maintenance window.

sudo systemctl stop mysql

# Navigate to the database directory
cd /var/lib/mysql/your_database_name

# Run a safe repair
sudo myisamchk -r your_table_name.MYI

# If that fails, try extended repair (slower, more thorough)
sudo myisamchk -r -e your_table_name.MYI

# Restart MySQL after
sudo systemctl start mysql

The -r flag does a standard recovery. Add --quick if the table is large and you want to skip rewriting the data file — but only use --quick if the index file is the only thing damaged.

Method 3: mysqlcheck with auto-repair (all engines, great for scripts)

This is my go-to for batch repairs on a VPS with multiple databases:

# Repair a single database
mysqlcheck -u root -p --auto-repair --optimize your_database_name

# Repair all databases
mysqlcheck -u root -p --auto-repair --optimize --all-databases

The --optimize flag reclaims fragmented space at the same time. It’s worth including — corrupted tables are often heavily fragmented.

Method 4: phpMyAdmin (for non-CLI users on shared hosting or cPanel)

1. Log in to cPanel and click phpMyAdmin under the Databases section.
2. In the left sidebar, click your database name to expand it.
3. Tick the checkbox next to the corrupted table name.
4. In the With selected dropdown at the bottom, choose Repair table.
5. Click Go.

phpMyAdmin will run REPAIR TABLE behind the scenes and show you a status row. Same limitation applies — this only works reliably for MyISAM.

Method 5: InnoDB crash recovery (when InnoDB won’t start)

This is the nastiest scenario. If MySQL won’t start at all because of InnoDB corruption, you need to force recovery mode. Edit your MySQL config:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
# On cPanel/WHM servers, the file is usually:
# /etc/my.cnf

Add this under the [mysqld] section:

[mysqld]
innodb_force_recovery = 1

Start MySQL and immediately dump the affected database:

sudo systemctl start mysql
mysqldump -u root -p your_database_name > /root/rescued_db.sql

If level 1 doesn’t get MySQL running, increment the value (2, 3, up to 6). Each level allows progressively more corruption to be bypassed. At level 6, the data you dump may be incomplete, but it’s better than nothing.

⚠ Warning: Never leave innodb_force_recovery set in production. Once you’ve dumped your data, remove that line, drop and recreate the database, reimport the dump, and restart MySQL normally.

Common Issues & Troubleshooting

“Table ‘./dbname/tablename’ is marked as crashed and should be repaired”

This is the classic MyISAM crash message. The table’s index file is flagged as inconsistent. Run REPAIR TABLE tablename; from the MySQL prompt. If that returns an error status, fall back to myisamchk -r with MySQL stopped.

mysqlcheck returns “error: 145” or “Can’t open file”

Error 145 is MySQL’s way of saying the table is marked as crashed. It’s the same underlying issue as above, just surfacing through a different tool. The fix is identical: REPAIR TABLE or myisamchk. If you’re also seeing file permission errors (especially after a server migration), check that all files in /var/lib/mysql/your_database_name/ are owned by the mysql user.

sudo chown -R mysql:mysql /var/lib/mysql/your_database_name/

REPAIR TABLE returns “note” instead of “OK” for InnoDB

InnoDB doesn’t support REPAIR TABLE the same way MyISAM does. The note you’re seeing isn’t an error — it’s MySQL telling you the command isn’t applicable. For InnoDB corruption, your options are: restore from backup, use innodb_force_recovery to dump and reimport, or (if the table structure is intact) try ALTER TABLE tablename ENGINE=InnoDB; which forces a table rebuild.

ALTER TABLE your_table_name ENGINE=InnoDB;

myisamchk fails with “Can’t create new tempfile”

You’re out of disk space. The repair process needs temporary working space equal to roughly the size of your .MYD data file. Check your free space with df -h and clear room before retrying. On a shared host, contact support — you may have hit your disk quota. On a VPS or dedicated server, you’ll need to free up space or expand the volume.

WordPress shows “Error Establishing a Database Connection” after a repair

The repair itself isn’t the cause here. This error usually means MySQL is still stopped, the database user lost permissions, or a table that WordPress needs (wp_options is the usual suspect) is still broken. Verify MySQL is running, then recheck all tables with mysqlcheck --check. Also confirm your wp-config.php credentials match what’s in cPanel under MySQL Databases.

FAQ