Fix MySQL Error 2006: Database Connection Lost

You're running a report or an import script, and halfway through, bam—MySQL Error 2006: 'Your connection to this database has been lost'. I've seen this a hundred times, most recently with a client who was running a nightly inventory sync that took 8 minutes but MySQL was set to timeout at 5. It's not a corrupt database. It's a timeout.

What actually triggers this

This error pops up when your MySQL server closes the connection while a query is still running. Common triggers:

Long-running SELECT or INSERT...SELECT queries (reports, backups, batch inserts)
Large LOAD DATA INFILE operations
PHP scripts with short max_execution_time that get killed mid-query
Network blips that reset the TCP connection
Connecting from a remote server with high latency

I had a client last month whose entire print queue died because of this—their PHP-based POS system ran a 10-second query every time a label printed, but the MySQL wait_timeout was set to 10 seconds exactly. One hiccup and every terminal lost connection.

The root cause (plain English)

MySQL has a few timeout settings that kill idle or slow connections:

wait_timeout – closes connections that sit idle for too long (default 28800 seconds = 8 hours, but many hosts set it to 30 or 60)
interactive_timeout – same thing but for interactive connections (command-line tools)
net_read_timeout – how long MySQL waits for a client to send data (default 30 seconds)
net_write_timeout – how long MySQL waits for a client to receive data (default 60 seconds)
max_execution_time (MySQL 5.7+) – kills queries that run longer than this (in milliseconds)

The fix is to bump these values so your query finishes before the timeout triggers.

Step-by-step fix

Step 1: Check current timeout values

Connect to MySQL and run:

SHOW VARIABLES LIKE '%timeout%';

Look at wait_timeout, interactive_timeout, net_read_timeout, and net_write_timeout. If any are under 300 (5 minutes), that's your problem.

Step 2: Increase them temporarily (for testing)

Run these SQL commands to bump them for the current session:

SET GLOBAL wait_timeout = 600;
SET GLOBAL interactive_timeout = 600;
SET GLOBAL net_read_timeout = 300;
SET GLOBAL net_write_timeout = 300;

If your query now runs fine, you've confirmed the fix.

Step 3: Make it permanent

Edit your MySQL config file. On Linux it's usually /etc/my.cnf or /etc/mysql/my.cnf. On Windows it's my.ini in the MySQL install directory.

Add these lines under the [mysqld] section:

[mysqld]
wait_timeout = 600
interactive_timeout = 600
net_read_timeout = 300
net_write_timeout = 300
max_execution_time = 600000

Restart MySQL:

sudo systemctl restart mysql   # systemd
sudo service mysql restart      # sysvinit

Step 4: Check the client-side

If you're using PHP, also check max_execution_time in php.ini. Set it to something higher than your longest query, like 600 seconds. Same for Python, Node, or any language—your script can't wait for a response if the script itself times out.

What to check if it still fails

Network latency: If you're connecting remotely, add --connect-timeout=10 (or higher) to your MySQL client command. The default is only 10 seconds.
Packet size: If you're sending huge blobs or TEXT fields, raise max_allowed_packet to 64M or 128M. MySQL drops the connection if a single row is bigger than this.
Firewalls or proxies: Some load balancers kill idle TCP connections after 60 seconds. Check your network gear.
MariaDB vs MySQL: MariaDB has extra timeout settings like wait_timeout_before_cleanup. Same fix applies, just check the doc for your version.
Persistent connections: If you're reusing connections in a pool, a connection that was fine 5 minutes ago might now be killed by the server. Use connection validation (e.g., SELECT 1 before running the real query).

That's it. Nine times out of ten, bumping the timeouts solves it. If it doesn't, check your network and your client-side script timeout. Don't blame the database—it's just protecting itself from zombie connections.