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

ERROR 2013 means the TCP connection between your client and MySQL died while a query was in flight. The client cannot see why; it only knows the socket ended mid conversation. Behind that one message sit several very different incidents: the server crashed or was OOM killed, a timeout fired on the server or on a proxy in between, someone killed the query, or the statement exceeded a packet limit. The server error log, read at the exact timestamp of the client error, tells you which incident you are actually in.

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

What this error means

While a statement executes, the client waits on the socket for results. If that socket closes before a complete response arrives, the client reports error 2013. The closure can come from mysqld dying (crash, OOM kill, restart), from mysqld deliberately ending the session (a KILL statement, max_execution_time, an administrator), from the network path (proxy idle timeout, VPN drop, flaky link), or from the protocol layer rejecting an oversized packet mid stream. Because the client message is identical in every case, diagnosis starts on the server, not the client.

Common causes

• The kernel OOM killer terminated mysqld during a memory heavy query, restarting the whole server and dropping every connection.
• A genuine mysqld crash (bug or corrupted page), visible as a stack trace plus InnoDB recovery in the error log.
• max_execution_time or an external query killer (pt-kill, an ORM statement timeout) terminating a long SELECT.
• A proxy, NAT gateway, or load balancer dropping the TCP session during a long silent phase of a query.
• net_read_timeout or net_write_timeout expiring while transferring a very large result set or bulk load over a slow link.
• A row or statement exceeding max_allowed_packet, which can surface as a lost connection rather than a clean packet error.

How to fix it

STABILIZE first. Confirm mysqld is up. If it crashed and restarted, verify InnoDB recovery completed and the service is accepting connections before doing anything else.

1. DIAGNOSE: check server uptime; a small number means a restart happened.

SHOW GLOBAL STATUS LIKE 'Uptime';

2. DIAGNOSE: read the server error log at the failure time, and check the kernel for an OOM kill.

tail -200 /var/log/mysql/error.log
dmesg -T | grep -i -E "out of memory|oom|killed process"

A signal message with a stack trace means a crash. mysqld: Out of memory or an OOM line in dmesg means memory. A clean log means the server never went down and you should look at timeouts and the path.

3. FIX a memory kill: reduce what one connection can consume and give the host headroom. The per session buffers (sort_buffer_size, join_buffer_size, tmp_table_size) multiply across connections, and an oversized innodb_buffer_pool_size leaves nothing for spikes.

SHOW VARIABLES WHERE Variable_name IN
('innodb_buffer_pool_size','sort_buffer_size','join_buffer_size','tmp_table_size','max_connections');

Size the buffer pool so buffer pool plus (per session buffers times realistic connection count) fits in RAM with margin.

4. FIX a fired timeout: if the query was killed for running long, first decide whether the query should be faster or the limit longer. Raise limits only for the session that needs it.

SHOW VARIABLES LIKE 'max_execution_time';
SET SESSION max_execution_time = 0;

For large transfers over slow links, raise the network timeouts for that session:

SET SESSION net_read_timeout = 600;
SET SESSION net_write_timeout = 600;

5. FIX the network path: enable TCP keepalives below the shortest middlebox timeout, and raise the proxy’s idle timeout where you control it. Configure the application pool to recycle connections and to test them before use so it never hands out a dead socket.

6. DIAGNOSE a packet limit: if the failure is tied to one large row or statement, check max_allowed_packet on both sides and raise it consistently.

SHOW VARIABLES LIKE 'max_allowed_packet';

How to prevent it

• Give the database host enough memory headroom that the OOM killer never selects mysqld, and alert on mysqld restarts explicitly.
• Keep pool connection lifetime and keepalives below every timeout on the path (server wait_timeout, proxy idle timeout).
• Make long jobs and large transfers use sessions with deliberately raised timeouts instead of loosening global settings.
• Chunk huge result sets and bulk loads so no single statement streams for many minutes.
• Monitor slow queries and kill patterns so a query killer and a critical report do not fight each other silently.
• Test failovers and restarts on purpose, so clients are proven to reconnect and retry cleanly.

When to call a senior engineer

Call for help when mysqld is crash looping or being OOM killed and the memory math does not add up, when connections keep dropping with a clean server log and the network path is a maze of proxies, or when recovery after a crash left you unsure about data integrity. Erzon engineers can correlate the client, server, and kernel evidence, tune the memory and timeout budget as one system, and leave the database stable under exactly the load that used to knock it over.