MySQL server has gone away
WordPress had a working database connection and lost it mid-request. The query is rarely at fault; the connection is.
WordPress database error MySQL server has gone away for query …
Three things drop a live connection: a query larger than max_allowed_packet, an idle period longer than wait_timeout, or MySQL restarting. Check whether the server has been up longer than the site has, because a low uptime answers the question immediately and the other two do not need testing.
What causes it, most likely first.
Work down the list. Each check is written to rule its row in or out before you change anything, because the fixes below it are different and a guess costs more than a command.
| Cause | How to check | Fix |
|---|---|---|
| A query bigger than max_allowed_packet | The failure follows a large import, a post with a very large serialised meta value, or a backup restore — and it fails at the same point every time rather than randomly. | Raise max_allowed_packet on the server to comfortably exceed the largest single statement. This is a server-side ceiling, so a client-side setting does not move it. |
| The connection idled past wait_timeout | Long admin operations fail near the end while ordinary page loads never do. The gap between two queries exceeded the timeout and MySQL closed the socket. | Raise wait_timeout, or break the work into shorter batches so no single connection sits idle that long. Batching is the more durable of the two. |
| MySQL restarted or was killed | Server uptime is shorter than the site's, or the error log records a shutdown. Out-of-memory kills are the usual reason on small machines. | Find why it stopped before restarting it. A database that was killed once for memory will be killed again under the same load. |
| The database is refusing new work | Errors cluster under load and clear when traffic drops, and the process list is close to max_connections. | Reduce what is holding connections rather than raising the limit. Long-running queries occupying slots are the cause; a higher ceiling only delays the same failure. |
Fixing it, step by step.
Commands assume WP-CLI and shell access. Where you have neither, each step says what it is doing so it can be done from the dashboard or over SFTP instead.
Ask how long the server has been running
An uptime shorter than the last time the site worked means the database restarted, and nothing else on this list needs checking.
mysqladmin status mysql -e "SHOW GLOBAL STATUS LIKE 'Uptime';"
Read the two limits that matter
Packet size and idle timeout account for most of what is left once a restart is ruled out.
mysql -e "SHOW VARIABLES WHERE Variable_name IN ('max_allowed_packet','wait_timeout','interactive_timeout');"Raise the packet ceiling if an import is failing
Set it in the server configuration rather than per session, so a restore run by any tool inherits it.
[mysqld] max_allowed_packet = 256M wait_timeout = 300
Check whether it was killed for memory
The kernel log names the process it chose. This is the single most common cause on a small server running MySQL next to PHP.
dmesg -T | grep -i -E 'out of memory|killed process' | tail -n 20
Retry the operation in smaller pieces
If the work is an import, batching keeps every statement well under the ceiling and every connection busy.
wp db import dump.sql wp db check
What the platform takes off the list.
The database runs in its own container with a memory allowance that belongs to it alone, so a PHP process that spikes cannot get MySQL killed by the kernel — the failure mode behind most of these errors on a single shared machine. Packet and timeout values are sized against that allowance rather than left at the distribution defaults that a large restore immediately exceeds.
Questions, answered.
Is my data damaged?
Why only during imports and backups?
Should I just set wait_timeout very high?
How is this different from “error establishing a database connection”?
If that was not it.
These fail in ways that look similar from the browser.