## TL;DR
Figure out which side gave up first. If the connection sat idle before the query, wait_timeout closed it; raise wait_timeout or validate connections in the pool before use. If the query itself was running when the error hit, the packet was too big (raise max_allowed_packet) or a network timeout fired mid-query (raise net_read_timeout and net_write_timeout).

```text
ERROR 2006 (HY000): MySQL server has gone away
```

## Steps
1. Check the timeouts: run SHOW VARIABLES LIKE 'wait_timeout'; and SHOW VARIABLES LIKE 'max_allowed_packet'; plus net_read_timeout and net_write_timeout. Expected: you see the current values (common defaults are 28800 seconds for wait_timeout and 64MB for max_allowed_packet).
2. Match the symptom to the cause. Idle connection, then the error on the first query, means wait_timeout closed it (or the pool handed you a dead connection). Error in the middle of a running query means packet size or net timeouts. Expected: you can name which case you are in.
3. For the idle case: raise wait_timeout, or enable connection validation on checkout in the pool so dead connections get recycled before your code sees them. Expected: no more errors on first-use-after-idle.
4. For the mid-query case: if you are inserting big blobs or long SQL text, raise max_allowed_packet on both client and server; if the query legitimately runs for minutes, raise net_read_timeout and net_write_timeout. Expected: the long query completes without the connection dropping.
5. Re-run the workload through a full idle-plus-work cycle and watch. Expected: zero ERROR 2006 occurrences.

## Use this when
- MySQL clients report "server has gone away"
- Errors appear on long queries or after idle periods
- Bulk inserts of large rows fail partway through
- A connection pool serves stale connections after quiet periods

## Not for this skill when
- You see "Lost connection to MySQL server during query" and the server restarted (check the error log; the server may have crashed)
- The error is access-denied (that is authentication, not timeouts)
- Replication reports "gone away" between primary and replica (check replica net timeouts separately)

## Variant phrasings
- mysql error 2006 server has gone away
- mysql wait_timeout vs max_allowed_packet
- mysql long query loses connection
- mysql server has gone away on insert

## Why it happens
MySQL closes connections idle longer than wait_timeout, and kills queries whose packets exceed max_allowed_packet or whose network stalls exceed the net timeouts. The client only discovers the dead connection when it next tries to use it, so the error surfaces on an innocent query that did nothing wrong.

## Edge cases
- Pools hide this; validate connections on checkout rather than only raising timeouts.
- SET GLOBAL does not affect existing connections, only new ones.
- Raising wait_timeout very high on a busy app leaks sleeping connections; fix the pool instead.
- max_allowed_packet must be raised on the client too, not just the server.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pTB5CwZhnZjWDZQVYC3wWA