Fixing ERROR 2013 (HY000): Lost connection to MySQL server during query

intermediate🗄️ MySQL2026-04-25| MySQL 5.7, MySQL 8.0+, MariaDB, Linux (Ubuntu/CentOS/Debian), Windows, Docker environments.

Error Message

ERROR 2013 (HY000): Lost connection to MySQL server during query
#mysql#database-administration#timeout#sql-error#performance

The Error Message

You’re halfway through a massive 5GB database migration or running a heavy JOIN across 10 million rows when suddenly, everything stops. Instead of your data, you see this frustrating message:

ERROR 2013 (HY000): Lost connection to MySQL server during query

This error is different from the common "MySQL server has gone away" message. While that usually happens when you first try to connect, Error 2013 strikes while the query is already in progress. The server starts the job, but the pipe breaks before the results reach your screen.

Why Connections Drop Mid-Query

Several bottlenecks usually cause this interruption. Most involve the server losing patience with the network or the size of the data packets:

  • Network Bottlenecks: The net_read_timeout or net_write_timeout limits expire while the server is still trying to push large chunks of data.
  • Oversized Packets: Your query result or the row you're inserting exceeds the max_allowed_packet limit.
  • Aggressive Firewalls: Network hardware or software might kill an "idle" TCP connection if a complex query takes 10 minutes to calculate before sending the first byte.
  • Physical Instability: A flaky VPN or a high-latency Wi-Fi connection can cause the TCP stack to reset.

Step-by-Step Fixes

Step 1: Bump Up Timeout Variables

The most frequent culprit is the server giving up on the client too soon. If you're fetching a massive result set over a slow connection, the default 30-second window is rarely enough. You need to expand these buffers.

Find your configuration file (usually /etc/mysql/my.cnf on Linux or my.ini on Windows) and look for the [mysqld] section. Add or update these values:

[mysqld]
# Wait longer for the client to send data (default is 30s)
net_read_timeout = 120
# Wait longer for the client to accept data (default is 60s)
net_write_timeout = 300
# Allow larger data packets (useful for BLOBs or long strings)
max_allowed_packet = 256M
# Keep the connection alive for longer operations
connect_timeout = 60

Once you've saved the changes, restart the service to apply them:

# Linux systems
sudo systemctl restart mysql

# Docker containers
docker restart <container_name>

Step 2: Change Settings Without a Restart

If you're dealing with a production environment where you can't afford a restart, run these commands in your MySQL terminal. These take effect immediately but will disappear if the server reboots.

SET GLOBAL net_read_timeout = 120;
SET GLOBAL net_write_timeout = 300;
SET GLOBAL max_allowed_packet = 268435456; -- 256MB in bytes

Step 3: Check Your Client Tools

Sometimes the server is fine, but your GUI tool has its own internal timer. If you use MySQL Workbench or DBeaver, the tool might be pulling the plug on the server.

  • MySQL Workbench: Navigate to Edit -> Preferences -> SQL Editor. Look for DBMS connection read timeout interval. If it's set to 600, try doubling it to 1200.
  • Command Line: If you're importing a massive SQL dump, pass the packet limit directly in the command:

mysql --max_allowed_packet=256M -u root -p my_database < backup.sql

  

### Step 4: Keep the TCP Connection Alive
On very long queries, firewalls might assume the connection is dead because no data has moved for several minutes. You can force the OS to keep the connection alive by adding `enable-tcp-keepalive` to your config. This sends small "heartbeat" packets to prevent the network from timing out.

## How to Verify the Changes
Don't just guess if the changes worked. Log into your MySQL shell and verify the current active variables with this command:

SHOW VARIABLES LIKE '%timeout%'; SHOW VARIABLES LIKE 'max_allowed_packet';


Confirm that `net_write_timeout` reflects your new value (e.g., 300). Now, try running your query again. If it finishes, your timeout windows were the issue.

## Proactive Optimization
While increasing timeouts stops the error, it’s often a temporary fix for slow queries. To solve the root problem, try these strategies:

  - **Chunk your data:** Instead of exporting 1,000,000 rows at once, use `LIMIT 0, 50000` and process the data in smaller batches.
  - **Run EXPLAIN:** Use `EXPLAIN` before your query. If you see "Full Table Scan," adding a single index could drop your execution time from 10 minutes to 10 milliseconds.
  - **Use SSH Tunnels:** If you are connecting to a remote server, run your query through an SSH tunnel. This often provides a more stable connection than a direct remote MySQL port.

Related Error Notes