MySQL Server Has Gone Away During Query Fix

Quick answer for advanced users: Check max_allowed_packet and wait_timeout in MySQL config. Increase them. Also look at net_write_timeout and net_read_timeout. Restart MySQL after changes.

This error pops up when MySQL kills your connection mid-query. It's common during big data imports, long-running reports, or when you're uploading large files like images or PDFs into a database. I've seen it in WordPress sites with huge media libraries, in data migration scripts, and even in simple SELECT queries on slow servers. The error message itself is short but frustrating: "MySQL server has gone away". Don't panic — it's usually a config tweak away from being fixed.

Why does this happen?

MySQL has limits. One is max_allowed_packet, which controls how big a single query (or result) can be. If your query is bigger than that, MySQL just closes the connection. Another is timeouts: if your query runs too long, MySQL kills it. The server might also crash or restart during heavy load. Or your network connection drops. So we need to check all these.

Step-by-step fix

1. Check current MySQL settings. Login to MySQL and run:

   SHOW VARIABLES LIKE 'max_allowed_packet';
   SHOW VARIABLES LIKE 'wait_timeout';
   SHOW VARIABLES LIKE 'net_write_timeout';
   SHOW VARIABLES LIKE 'net_read_timeout';

   Default max_allowed_packet is often 16MB or 64MB. wait_timeout is 28800 seconds (8 hours) by default, but some hosts set it to 60 seconds. That's a trap.
2. Increase max_allowed_packet. Open your MySQL config file (my.cnf on Linux, my.ini on Windows). Usually in /etc/mysql/ or /etc/my.cnf. Add or change:

   [mysqld]
   max_allowed_packet = 256M
   wait_timeout = 600
   net_write_timeout = 60
   net_read_timeout = 60

   256M is safe for most cases. If you're inserting huge data, go up to 1G. Save and restart MySQL: sudo systemctl restart mysql or sudo service mysql restart.
3. Test the fix. Run your problematic query again. If it works, you're golden. If not, move to the next step.
4. Check server resources. If MySQL keeps crashing, look at memory and CPU. Use top or htop. Low memory can cause MySQL to die. Also check logs: /var/log/mysql/error.log or /var/log/mysqld.log. Search for "Out of memory" or "Killed". If the server kills MySQL, you need more RAM or tune buffer sizes.
5. Check query size directly. In PHP, you can split big queries into batches. For example, instead of one INSERT with 10,000 rows, do 10 inserts of 1,000 rows each. This avoids hitting the packet limit.

Alternative fixes if it still fails

• Increase timeout for long queries. If your query runs for hours (like a backup or report), set wait_timeout to a higher value (e.g., 3600 for 1 hour). But be careful — too high can keep connections open and waste resources.
• Use persistent connections. In PHP, mysqli_pconnect() or PDO::ATTR_PERSISTENT can help if the connection drops frequently. But persistent connections have their own issues (like locking). Only use if you know what you're doing.
• Upgrade MySQL server. If you're on MySQL 5.6 or older, upgrade to 8.0. Newer versions handle large queries better. I've seen this error disappear after an upgrade.
• Check network connection. If you're connecting remotely, test with a simple ping or telnet. A flaky network can drop the connection. Add connect_timeout=10 to your connection string.
• Increase max_allowed_packet at session level. If you can't change the global config, you can set it per session: SET SESSION max_allowed_packet = 256 * 1024 * 1024; But this only works for that connection and resets on reconnect.

Prevention tips

Once you've fixed it, don't let it happen again. Here's what I do:

• Set max_allowed_packet to 256MB as a baseline. It's safe for 99% of use cases.
• Monitor your queries. Use SHOW PROCESSLIST; to see long-running ones. Kill them if they hang.
• Batch your large operations. For big INSERTs, use LOAD DATA INFILE or chunk them with LIMIT.
• Set up alerts for MySQL errors. Tools like Nagios or Zabbix can tell you when "gone away" pops up.
• Use a connection retry logic in your code. In PHP, wrap the query in a try-catch and retry once. That saved me many times.

"I had this error every night during my cron job. Turned out my max_allowed_packet was only 16MB. Changed to 256M and it's been running smooth for 2 years." — Real comment from a user on my old blog.

One last thing: if you're using a shared host, you probably can't edit my.cnf. In that case, ask support to increase max_allowed_packet. Or switch to a VPS. Most shared hosts won't allow it, and they'll tell you to use smaller queries. That's a sign to move on.

That's it. Fix the packet size, check timeouts, and your query will run. I know this error is infuriating — I lost a weekend to it once. But now you have the fix. Good luck.