2026年11月14日

2026年11月14日

Fix WordPress Database Errors: Connection, Crashed Tables, InnoDB

This article is a localized edition of the Japanese original. Read the Japanese original

WordPress database errors fall into two broad groups: you "can't connect to the database", or you "can connect but a table has a problem". The fix is completely different depending on the cause, so first figure out which one you have. This article was checked against the WordPress 6.9 source code and the official MySQL 8.4 manual as of November 2026.

Error shown Main causes Section
"Error establishing a database connection" Wrong connection details, MySQL/MariaDB stopped, connection limit reached, disk full Step 1
Table './db/wp_posts' is marked as crashed and should be repaired A corrupted MyISAM table Steps 3 and 4
Table 'db.wp_xxx' doesn't exist Mismatched table prefix, missing tables Step 5
MySQL won't start, or the log records InnoDB corruption Corrupted InnoDB data files Step 6

Repair operations change your data. Before you start, take whatever backup you can (the official MySQL manual also says to back up before REPAIR TABLE).

# If WP-CLI is available
wp db export ~/backup-before-repair.sql

# With mysqldump (-p prompts for the password)
mysqldump -u wp_user -p wp_database > ~/backup-before-repair.sql

Writing the password directly on the command line leaves it in your shell history and the process list, so pass only -p and type it when prompted.

Step 1: Find the cause of a connection error

"Error establishing a database connection" appears when WordPress can't connect to the database with the details in wp-config.php. Check the following in order.

1. Check the connection details

Make sure these four values in wp-config.php match the actual database.

<?php
define( 'DB_NAME', 'wp_database' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'your-password' );
define( 'DB_HOST', 'localhost' );

On shared hosting, DB_HOST may be a host name specified by the hosting company (something like mysqlXXX.example.ne.jp) rather than localhost. Compare it with the value shown in your server's control panel. Another common cause is changing the database password in the control panel and forgetting to update wp-config.php.

2. Try connecting from the command line with the same details

mysql -u wp_user -p -h localhost wp_database -e 'SELECT 1;'

Access denied points to a username, password or privilege problem (Fixing MySQL Access denied errors); Can't connect means MySQL is stopped or the host name is wrong. When DB_HOST is localhost, both PHP and the mysql command connect through a UNIX socket; with 127.0.0.1 they connect over TCP. If only one of them fails, check the socket path and MySQL's listening settings.

If you can't use SSH and want to check with PHP, put the following file outside the public directory and run it from the command line, as in php test-db.php. Placing it where it can be opened from the web risks leaking your connection details. From PHP 8.1 on, mysqli throws an exception when the connection fails, so catch it with try/catch.

<?php
// test-db.php (delete it when you're done)
try {
	$conn = new mysqli( 'localhost', 'wp_user', 'your-password', 'wp_database' );
	echo 'OK: ', $conn->server_info, PHP_EOL;
	$conn->close();
} catch ( mysqli_sql_exception $e ) {
	echo 'NG: ', $e->getMessage(), PHP_EOL;
}

3. Check that MySQL/MariaDB is running (VPS or dedicated server)

systemctl status mysql      # MySQL (Ubuntu/Debian)
systemctl status mariadb    # MariaDB
systemctl status mysqld     # MySQL (RHEL-based)

# Check the logs for why it stopped
sudo journalctl -u mysql -n 50 --no-pager
sudo tail -n 50 /var/log/mysql/error.log

# Free disk space
df -h

If it is stopped, start it; if it won't start, decide based on the log. If it was killed for lack of memory (the log shows Out of memory or oom-kill), review MySQL's settings and how other processes use memory. If the log records InnoDB corruption, go to Step 6.

If you've hit the connection limit (Too many connections), also suspect a traffic spike or bots.

Step 2: Check the tables’ storage engine

How you repair depends on the table's storage engine. WordPress doesn't specify an engine when it creates tables, and InnoDB has been MySQL's default since 5.5, so tables on current sites are usually InnoDB. On older sites, MyISAM tables may remain.

SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'wp_database';
Engine REPAIR TABLE Main remedy when corrupted
MyISAM Supported REPAIR TABLE, mysqlcheck, the WordPress repair page
InnoDB Not supported (the CHECK TABLE check works) Restore from backup, or extract data with innodb_force_recovery

The official MySQL manual also says REPAIR TABLE works for MyISAM, ARCHIVE and CSV tables. For the differences between the two engines, see InnoDB vs. MyISAM.

Step 3: Use the WordPress repair page

WordPress has a page that checks and repairs tables (wp-admin/maint/repair.php).

Add the following line to wp-config.php, above the "That's all, stop editing!" line.

<?php
define( 'WP_ALLOW_REPAIR', true );

Then do the following.

  1. Open https://example.com/wp-admin/maint/repair.php in your browser.
  2. Click "Repair Database" or "Repair and Optimize Database". Optimizing locks the tables and can take a while, so start with repair only.
  3. After checking the results, remove the line you added from wp-config.php right away.

This page can be opened without logging in. If you leave the setting in place, anyone can run a repair or optimization.

The repair page runs CHECK TABLE on each table and runs REPAIR TABLE only on tables that report a problem. If a problem is found in an InnoDB table, REPAIR TABLE can't fix it, so the page reports that the repair failed. In that case, see Step 6.

Step 4: Repair with mysqlcheck or SQL (MyISAM)

If WP-CLI is available, check with the following commands and repair if needed.

wp db check     # Check all tables (same as mysqlcheck --check)
wp db repair    # Try to repair (same as mysqlcheck --repair; has no effect on InnoDB)

When using mysqlcheck directly, check first and let it automatically repair only the tables found to be corrupt.

# Check only (the default)
mysqlcheck -u wp_user -p wp_database

# Check, and repair only the tables found to be corrupt
mysqlcheck -u wp_user -p --auto-repair wp_database

To do it with SQL from phpMyAdmin or the mysql command, name the tables.

CHECK TABLE wp_posts, wp_postmeta, wp_options;
REPAIR TABLE wp_posts;

If Msg_text is OK, there's no problem. Running REPAIR TABLE on an InnoDB table returns a message that the engine doesn't support repair. For the WP-CLI procedure, also see Repairing the database with WP-CLI.

Step 5: When you see “table doesn’t exist”

First, check that the table prefix in wp-config.php matches the actual table names in the database. Prefixes can get out of sync after a server migration or a backup restore.

# The prefix in wp-config.php
wp config get table_prefix

# List every table in the database
wp db tables --all-tables

For example, if wp-config.php says wp_ but the tables look like wpabc_posts, set $table_prefix to the actual prefix.

If the prefix matches and the tables are still missing, the tables themselves are gone. Restore them from a backup. wp core install creates a new site; it can't bring back lost data.

Step 6: Recover from InnoDB corruption

When InnoDB data files are corrupted, MySQL may fail to start or may stop when a particular table is read. Restoring from a backup is the most reliable fix. If you have no backup, or need to extract newer data, start MySQL with innodb_force_recovery and dump the data.

Value What it does Caution
1-3 Skips corrupt pages, stops background processing or rollbacks, and so on If you can dump the data, usually only data on the corrupt pages is lost
4-6 Stops even more processing Can permanently corrupt the data files. The official docs ask you to test on a separate physical copy first

With any nonzero value, InnoDB rejects INSERT, UPDATE and DELETE (values of 4 or higher make it read-only). WordPress won't work normally either, so this assumes the site is taken offline during the work.

Procedure (Ubuntu example):

# 1. Stop MySQL and copy the entire data directory
sudo systemctl stop mysql
sudo cp -a /var/lib/mysql /var/lib/mysql.broken-copy

# 2. Add innodb_force_recovery = 1 to the [mysqld] section of the config file
#    MySQL: /etc/mysql/mysql.conf.d/mysqld.cnf
#    MariaDB: /etc/mysql/mariadb.conf.d/50-server.cnf
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
innodb_force_recovery = 1
# 3. Start it and dump the data
sudo systemctl start mysql
mysqldump -u wp_user -p wp_database > ~/wp_database-recovered.sql
  • If it won't start, or the dump stops partway, raise the value one step at a time to 2, then 3. Try 4 or higher only on the copied data first.
  • Once the dump succeeds, remove the innodb_force_recovery line from the config file (set it back to 0) and restart MySQL.
  • Create a new database, import the dump into it (mysql -u user -p new_database_name < ~/wp_database-recovered.sql), and point DB_NAME in wp-config.php to the new database. Keep the original database until you have confirmed the new one works.

Summary

  • First tell whether you "can't connect" or "a table has a problem". For connection errors, check the connection details, MySQL's status and free disk space in that order.
  • Take a backup before repairing.
  • REPAIR TABLE, mysqlcheck's repair and the WordPress repair page work on MyISAM tables. Remove WP_ALLOW_REPAIR as soon as you're done.
  • For "table doesn't exist", suspect a prefix mismatch first; if the tables really are gone, restore from a backup.
  • Handle InnoDB corruption by restoring from a backup, or by raising innodb_force_recovery from 1 and dumping the data.

For how to take regular backups, see Database backups.

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)

お気軽にご相談ください

お見積りへ お問い合わせへ
▲