Safe phpMyAdmin Fixes for WordPress Database Problems

Before changing anything in phpMyAdmin, export the WordPress database. Database edits take effect immediately, and phpMyAdmin does not provide a reliable undo button. If your host offers snapshots or on-demand backups, create one there as well.

Then identify the exact problem. An “Error establishing a database connection” does not automatically mean the tables need repair. Incorrect credentials, an unavailable database server, and damaged tables require different fixes.

Confirm that you opened the correct database

Open wp-config.php through your hosting file manager or SFTP and find these values:

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_HOST', 'localhost' );

$table_prefix = 'wp_';

Do not share the database password or paste the complete file into a support ticket.

In phpMyAdmin, select the database matching DB_NAME. Its WordPress tables should begin with the configured $table_prefix. The prefix is often wp_, but it can be different.

If the database is missing from phpMyAdmin, stop there. The database user might not have access to it, or you may be signed into the wrong hosting account. Contact the host instead of creating replacement tables.

Export a rollback copy

With the correct database selected:

1. Open Export.
2. Choose the quick export method unless you need to exclude specific tables.
3. Select SQL format.
4. Download the export and confirm that the file is not empty.

Keep this copy unchanged. If an edit causes a new problem, restore it through your host’s backup system or phpMyAdmin’s Import tab. Import limits vary by host, so large databases may require support assistance or a command-line restore.

Check whether the WordPress tables are present

A standard installation normally contains tables for posts, options, users, comments, terms, and metadata. With the default prefix, examples include:

• wp_options
• wp_posts
• wp_postmeta
• wp_users
• wp_usermeta

A plugin may add many more tables. Their presence alone is not evidence of corruption.

If every table is missing, confirm DB_NAME and $table_prefix in wp-config.php. Do not create empty WordPress tables manually. Empty replacements will not restore the site’s content or settings.

If only one or two core tables are missing, restore them from a known-good backup. Repair operations cannot reconstruct a deleted table.

Inspect the site address without changing it first

Incorrect URL values can cause redirect loops, failed logins, or links that send visitors to an old domain.

First confirm whether the installation uses WordPress Multisite. A Multisite database can contain separate options tables for individual sites as well as network-level URL and domain settings. Editing siteurl or home in the wrong table can affect the wrong site or leave the network configuration inconsistent. If Multisite is enabled, use the network administration tools or follow the host’s Multisite-specific procedure instead of changing URL rows without confirming their purpose.

For a standard single-site installation, open the table ending in _options, then locate these rows:

• siteurl
• home

You can also use the SQL tab for a read-only check. Replace wp_ if your site uses another prefix:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Both values should normally use the site’s intended scheme and hostname, such as https://example.com. A subdirectory installation may legitimately use different paths, so check the site configuration before editing either row.

To correct a clearly wrong value, edit the individual row in phpMyAdmin. Change only option_value, save it, and test the site in a private browser window.

If the change makes the site less accessible, restore the original value immediately. WordPress can override these rows with the WP_HOME and WP_SITEURL constants in wp-config.php, so a database edit will not help when the relevant constant is defined there.

Repair only tables reported as damaged

Do not select every table and run repair as routine maintenance. Use it when MySQL or WordPress reports a damaged table, an incorrect key file, or a table marked as crashed.

In phpMyAdmin:

1. Select the affected database.
2. Check only the table named in the error.
3. Choose Repair table from the bulk-action menu.
4. Retest the failed WordPress action.

WordPress documents a database table repair procedure. Repair support depends on the table’s storage engine and the database server. If phpMyAdmin reports that repair is unsupported or fails repeatedly, give the exact table name and database error to your host.

Do not empty or drop a table as a repair attempt. Empty deletes every row while preserving the table structure; Drop removes the table itself.

Use table size to investigate database growth

A large database is not necessarily damaged, but a single fast-growing table can cause slow backups, failed imports, or excessive storage use.

If WP-CLI is available, this command lists table sizes using the credentials in wp-config.php:

wp db size --tables

The wp db command documentation lists the available database operations.

In phpMyAdmin, the database’s Structure view also shows table sizes. Look for a table that is disproportionately large, then identify which plugin or WordPress component owns it before deleting anything.

Avoid deleting rows from options, metadata, scheduled-action, session, or log tables based only on size. Plugins may depend on those records, and some option values contain serialized data that can break if edited as plain text. Use the owning plugin’s cleanup tool or vendor instructions when available.

Treat connection errors separately

If phpMyAdmin opens the database and displays its tables, the database is reachable with your phpMyAdmin account. WordPress may still be using different credentials.

Compare DB_NAME, DB_USER, and DB_HOST in wp-config.php with the values provided by your host. Do not change the database password in phpMyAdmin unless you can also update the hosting database user and wp-config.php together.

When the values appear correct but WordPress still cannot connect, ask the host to verify:

• The database server is running.
• The configured database user exists.
• That user has access to the selected database.
• DB_HOST includes any required hostname, port, or socket.
• The server is not rejecting the connection because of TLS or certificate settings.

These are server and account checks. Repairing tables or editing wp_options will not fix them.

Avoid broad search-and-replace queries

Moving from HTTP to HTTPS or changing domains affects URLs across many tables. A raw SQL replacement that changes every occurrence of an old domain can damage serialized plugin and theme settings.

Use a serialization-aware migration tool or WP-CLI instead. Keep the database export until you have tested the front end, administration area, media, forms, and scheduled tasks.

For unexplained failures that remain after these checks, follow the official WordPress troubleshooting guidance and review the precise error in the hosting logs. The error text and table name are more useful than applying additional phpMyAdmin changes at random.