How to Fix a WooCommerce Database Connection or Query Problem

A WooCommerce database connection or query problem can take down the entire site or cause narrower symptoms, including missing products, outdated sale prices, failed orders, and admin pages that never finish loading. First determine whether WordPress cannot connect to MySQL at all or WooCommerce is failing on a particular query. The fixes are different.

Before changing files or database tables, create a current backup. For a store that is still accepting orders, perform conflict tests and database repairs on a staging copy whenever possible.

Identify the type of database problem

An “Error establishing a database connection” page usually means WordPress cannot connect to its configured database. Common causes include:

• The database service is unavailable.
• The credentials or database host in wp-config.php are wrong.
• The hosting account has reached a database connection or resource limit.
• A database server restart or network interruption broke existing connections.

A query problem is usually more selective. The storefront may load while products disappear from a catalog, scheduled sales remain active, reports fail, or checkout produces an error. In that case, look for a failed SQL query, a missing WooCommerce table, stalled background actions, or a plugin conflict.

Do not start by changing database credentials if the rest of WordPress is working. Valid credentials are unlikely to explain a problem limited to one WooCommerce screen or process.

Check whether the database is reachable

Open the WordPress dashboard and several unrelated front-end pages. If every request shows a database connection error, check your hosting control panel for a MySQL or MariaDB outage.

If you have SSH and WP-CLI access, run:

wp db check

The wp db check command uses the credentials in wp-config.php to check the database tables. It also requires the database client utilities used by WP-CLI, including mysqlcheck. The command may therefore be unavailable on restricted hosting even when WordPress can connect normally. In that case, use your host’s database tools or ask its support team to perform the check.

If the command cannot connect, inspect these values in wp-config.php:

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

Compare them with the database details supplied by your host. DB_HOST is not always localhost; managed hosts may use a separate hostname or socket.

Do not paste these values into a support ticket, forum post, or screenshot. If the settings are correct but connections still fail, ask the host to check:

• Whether the database service is running
• Whether the database user still has access
• Connection and resource limits
• Recent MySQL or MariaDB restarts
• Storage exhaustion or a read-only database state

Report intermittent errors with their exact timestamps. The host may need those times to find the corresponding server-log entries.

Inspect WooCommerce status and logs

When WordPress loads but WooCommerce data is wrong or missing, go to WooCommerce > Status.

The Database section shows the WooCommerce database version, table sizes, storage engines, and whether expected tables exist. WooCommerce explains these fields in its System Status documentation.

Check for:

• A WooCommerce database version older than the installed plugin version
• Missing WooCommerce or Action Scheduler tables
• An unusually large table related to the failing feature
• Failed or overdue scheduled actions
• Fatal errors recorded when the problem occurred

Open the Logs tab and select the relevant fatal-errors log. Search for the affected product ID, order ID, table name, or phrases such as:

WordPress database error
Table doesn't exist
Unknown column
Deadlock found
MySQL server has gone away

The exact message determines the next step. A missing column can indicate an incomplete database update. A “server has gone away” message requires the host to investigate timeouts, database restarts, packet limits, or resource constraints.

Check scheduled actions

WooCommerce uses background processes for scheduled sales, emails, subscriptions, and data updates. A working database connection does not guarantee that these jobs are completing.

Go to WooCommerce > Status > Scheduled Actions and filter by Failed or Pending. Open relevant actions to inspect their error details.

A few old failures are not necessarily the cause. Look for repeated failures that match the affected feature and time. For example, a growing queue of overdue actions can explain why a scheduled sale remains active after its end date.

You can also confirm that WordPress cron events are registered:

wp cron event list --fields=hook,next_run_relative,recurrence

Look for action_scheduler_run_queue. If it is missing, or scheduled actions remain overdue, check whether DISABLE_WP_CRON is enabled in wp-config.php. Some hosts disable WordPress’s request-driven cron and replace it with a server cron job. Confirm that the replacement job is running before changing this setting.

Do not repeatedly run every failed action on a live store. Payment, subscription, and email actions can have duplicate side effects. Correct the underlying error, then test one relevant action.

Complete a pending WooCommerce database update

WooCommerce may need to update its database schema after a plugin upgrade. If the dashboard displays a database update notice, or the System Status report shows an older WooCommerce database version, take a fresh database backup and run the update offered by WooCommerce.

After starting the update, monitor Scheduled Actions for failed update jobs. Large stores may process the update in batches.

Do not manually change the WooCommerce database version stored in WordPress options. Doing so can hide an incomplete migration without creating the required tables or columns.

Test for a plugin or theme conflict

A plugin can alter product queries, interfere with scheduled actions, or load an incompatible database library. Use a controlled conflict test on staging to isolate it.

Follow WooCommerce’s recommended conflict-testing process:

1. Update WooCommerce, its extensions, and the active theme after confirming backup compatibility.
2. Switch temporarily to a default WordPress theme or Storefront.
3. Deactivate every plugin except WooCommerce and the extension directly involved in the error.
4. Repeat the exact action that fails.
5. Reactivate plugins one at a time, testing after each activation.

If disabling a plugin stops the problem, leave it disabled while contacting its vendor. Include the relevant error and the steps that trigger it, but remove credentials and customer data.

Also check must-use plugins and database drop-ins, which are not always disabled through the normal Plugins screen. Files such as wp-content/object-cache.php and wp-content/db.php can affect queries even when ordinary plugins are inactive.

Enable a temporary WordPress debug log

If WooCommerce logs do not capture the failure, enable WordPress logging on staging or during a short diagnostic window.

First check wp-config.php for existing WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY definitions. Change their existing values rather than adding duplicate definitions. If they are not already present, add them before the final stop-editing line:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reproduce the problem once, then inspect wp-content/debug.log. WordPress documents these settings in its debugging guide.

After diagnosis, remove all three temporary constants if you added them. If they existed previously, restore their original values. At minimum, ensure the existing debug setting is changed back to:

define( 'WP_DEBUG', false );

Do not add this line if WP_DEBUG is already defined elsewhere.

Debug logs can contain file locations, query fragments, email addresses, and other private information. Remove the temporary log after reviewing it, and do not send the complete file without checking it for sensitive data.

Repair tables only when a check reports damage

Do not optimize, repair, or modify tables merely because a WooCommerce page is slow. First run wp db check or use your host’s database tools to confirm that a table is damaged.

If corruption is reported, take a database backup and ask the host to repair the named table. Restoring the affected table from a known-good backup may be safer when a repair fails.

Avoid manually deleting WooCommerce tables, Action Scheduler tables, options, or product metadata. Reinstalling WooCommerce does not restore lost store data. If a database change makes the problem worse, stop writes to the store where practical and restore the pre-change database backup before accepting new orders.