1. The Usual Suspect: max_allowed_packet Too Small
This error trips up almost everyone the first time they import a database backup larger than a few megabytes. I've seen it happen when restoring a WordPress multisite export from a 50MB file or importing a WooCommerce orders dump. MySQL just gives up because the packet it's trying to receive is bigger than what it allows.
Here's the fix. Before importing, check your current setting:
SHOW VARIABLES LIKE 'max_allowed_packet';
Default is often 4MB or 16MB. That's too small for any real-world import. Bump it to at least 64MB. On a Linux server, edit /etc/my.cnf or /etc/mysql/my.cnf and add under [mysqld]:
[mysqld]
max_allowed_packet = 64M
Then restart MySQL:
sudo systemctl restart mysql
If you can't restart (shared hosting, I feel your pain), set it per session in your import command:
mysql --max_allowed_packet=64M -u user -p database_name < dump.sql
Skip trying to set it via phpMyAdmin's interface—it's unreliable. The command line is your friend here. This change fixes about 60% of 'server has gone away' cases.
2. Timeouts: wait_timeout and net_read_timeout
Even with a large packet size, if your import takes longer than MySQL's patience, it'll drop the connection. The default wait_timeout is 28800 seconds (8 hours)—that's fine. But net_read_timeout defaults to 30 seconds. That's the killer.
When MySQL is reading data from the client (you, during import), if it doesn't receive data for 30 seconds, it assumes you're gone and disconnects. I've seen this happen on slow network connections or when importing a huge INSERT statement that takes 40 seconds to generate on the client side.
Check your current settings:
SHOW VARIABLES LIKE 'net_read_timeout';
SHOW VARIABLES LIKE 'wait_timeout';
Set both to something reasonable for your import. I usually go with:
[mysqld]
wait_timeout = 600
net_read_timeout = 300
interactive_timeout = 600
Restart MySQL or set them per session. For a quicker fix without restart:
SET GLOBAL wait_timeout = 600;
SET GLOBAL net_read_timeout = 300;
SET GLOBAL interactive_timeout = 600;
Then run your import. This nails another 25% of cases.
3. The Sneaky One: Row Size Exceeds max_allowed_packet
Sometimes your import file itself is fine, but a single row (like a serialized PHP array in WordPress) exceeds the packet limit. This is rarer but infuriating—the import starts, runs for a while, then dies mid-way with 'server has gone away'.
To check, look at your MySQL error log:
sudo tail -f /var/log/mysql/error.log
You'll see something like: 'Packet for query is too large (10,000,048 bytes). You can change this value on the server by setting max_allowed_packet.'
The fix is the same as #1: increase max_allowed_packet further. But if you can't change the MySQL config (e.g., on cheap shared hosting), you have another option: split the import file. Use tools like mysqldumpsplitter or just manually edit the SQL file to break large INSERT statements into smaller chunks. I've done this by saving a backup, opening the .sql file in a text editor, and adding LIMIT 1000 after each INSERT. It's a pain, but it works.
Quick Reference Summary
| Cause | Symptom | Fix |
|---|---|---|
| max_allowed_packet too small | Error right away or mid-import for large SQL file | Increase to 64M+ in my.cnf or via command line |
| net_read_timeout too short | Error after 30 seconds of inactivity | Increase to 300 seconds |
| Single row exceeds limit | Error after import starts, then fails at a specific row | Increase max_allowed_packet or split INSERTs |
Start with #1. It's the most common fix. If that doesn't work, move to #2. #3 is your last resort. I've been doing this for years, and these three settings cover almost every 'server has gone away' case I've seen.