MySQL Workbench drops connection mid-query? Here's why

You're running a big query, and suddenly it dies

This happens when you're working on a big data export or a complex join. You click execute, wait a few seconds, and then see: Error Code: 2013. Lost connection to MySQL server during query. The query gets killed, and you have to start over. I've seen this with a client who tried to export 2 million customer records – it failed three times before we fixed it.

Why does this happen?

Plain and simple: the server or the client gives up. Either your query takes too long and hits a timeout, or the data you're sending back is too big and hits a packet limit. Sometimes it's a firewall that closes the connection because it looks idle. But the main triggers are:

• wait_timeout – the server kills idle connections after a set time (default 28800 seconds, but can be lower).
• interactive_timeout – same, but for interactive clients like Workbench.
• max_allowed_packet – if your result set is bigger than this (default 4MB), the connection drops.
• Network instability or firewall rules that cut long-lived TCP connections.

The fix: adjust MySQL settings

You need to change three settings on the server. If you don't have access to the MySQL config file (my.cnf or my.ini), ask your hosting provider or DBA. Here's what to do:

Step 1: Open your MySQL config file

On Linux, it's usually /etc/mysql/my.cnf or /etc/my.cnf. On Windows, look in C:\ProgramData\MySQL\MySQL Server X.X\my.ini. Open it with a text editor as root or administrator.

Step 2: Add or change these lines under [mysqld]

[mysqld]
wait_timeout = 600
interactive_timeout = 600
max_allowed_packet = 128M

Why these numbers? 600 seconds gives you 10 minutes per query – enough for most reports. If you're doing huge exports, bump it to 1800 (30 minutes). The 128MB packet size handles most result sets. If you're dumping gigabytes, use 256M or 512M.

Step 3: Restart MySQL

On Linux: sudo systemctl restart mysql. On Windows: Open Services (services.msc), find MySQL, right-click and restart. After restart, the settings take effect.

Step 4: Try the query again

Open a fresh session in Workbench and rerun your query. If it works, you're done. If not, move to the next step.

If it still fails: check Workbench settings

Workbench also has its own timeout. Go to Edit → Preferences → SQL Editor. Look for DBMS connection read timeout. Set it to 600 seconds (or higher). Also uncheck Limit rows if you're exporting everything. Apply and restart Workbench.

Still no luck? Firewall or network issue

Had a client last month whose IT team set a 5-minute idle timeout on their AWS security group. If your query takes longer, the firewall drops the connection. Check with your network team if there's a timeout on your router or cloud security group. You can also test by connecting from a local MySQL client (like mysql command line) to see if the same query runs fine.

Quick checklist if you're stuck

One more thing: if you're running a stored procedure that takes hours, consider breaking it into smaller chunks. Not everything needs to be one giant query.

That's it. Start with the timeout and packet size changes – they fix 90% of these cases. The rest is network or firewall. Good luck.