Introduction

When MySQL Workbench disconnects after sitting idle, the cause is usually not Workbench alone. The effective timeout can come from the MySQL server, an SSH tunnel, a firewall, or a network device in the middle. Keeping the connection alive usually means identifying which layer is dropping the session and adjusting that layer deliberately.

Start with the Server Timeouts

MySQL itself closes idle sessions based on timeout settings. The two variables most often involved are:

• 'wait_timeout'
• 'interactive_timeout'

You can inspect them with:

SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'interactive_timeout';

If the values are too low for your workflow, increase them at the server level.

For the current running server:

SET GLOBAL wait_timeout = 28800;
SET GLOBAL interactive_timeout = 28800;

Those changes are temporary unless also placed in the server configuration file.

A typical MySQL configuration fragment:

[mysqld]
wait_timeout=28800
interactive_timeout=28800

Then restart MySQL for permanent effect.

Workbench Has Its Own Keepalive Behavior

MySQL Workbench also has client-side behavior that can help keep sessions from appearing idle. In Workbench preferences, there is a DBMS keepalive setting that sends periodic activity to prevent the server from treating the connection as inactive.

This is useful when:

• you want to keep an interactive SQL editor open for a long time
• the server timeout is reasonable but still shorter than your working pattern
• you do not want to change server-wide timeout policy for everyone

Client keepalive is often the least intrusive fix when the problem is mainly your own desktop session rather than the whole database server configuration.

SSH Tunnels Are a Separate Layer

If Workbench connects through SSH, the database session may be fine while the SSH tunnel is what actually drops.

In that case, SSH keepalive settings matter more than MySQL settings.

For OpenSSH config, a typical pattern is:

Host my-db-host
    ServerAliveInterval 60
    ServerAliveCountMax 3

If you use PuTTY or another SSH client, look for a similar keepalive interval setting. Otherwise the tunnel may die even though MySQL itself would have allowed the session to continue.

Network Devices Can Drop Idle Sessions Too

Even with generous server and SSH timeouts, a firewall, VPN, load balancer, or NAT device may close idle TCP connections. That is why a timeout problem can persist after changing MySQL variables.

A useful mental model is:

• MySQL can close the session
• SSH can close the tunnel
• the network path can close the TCP connection
• Workbench can only control part of this stack

If disconnects happen at a very regular interval that ignores your MySQL timeout settings, suspect the network path.

Use a Periodic Query Only as a Last Resort

Some developers keep a connection alive by running a harmless query periodically, such as:

SELECT 1;

That works technically, but it is usually a fallback rather than the best first solution. Prefer proper server, client, or SSH keepalive settings before building ad hoc polling habits.

Balance Convenience Against Resource Use

Long-lived idle connections are not always desirable. Higher timeout values keep workflows smooth, but they also hold server resources longer and can hide abandoned sessions.

That means the right setting depends on your environment:

• local development can often tolerate longer timeouts
• shared production servers may need stricter idle policies
• DBAs may prefer shorter timeouts plus explicit reconnect behavior

The answer is operational, not just technical.

Common Pitfalls

A common mistake is changing only Workbench settings when the real disconnection comes from MySQL server timeout values.

Another mistake is changing MySQL timeout values when the connection is actually going through an SSH tunnel that is timing out first.

People also often forget that network devices can drop idle sessions independently of both Workbench and MySQL.

Finally, do not raise server-wide timeouts casually on shared systems without considering resource and security policy tradeoffs.

Summary

• Idle disconnects in MySQL Workbench can come from MySQL, SSH, or the network path
• Check wait_timeout and interactive_timeout first on the server
• Use Workbench keepalive settings when the issue is mainly an interactive client session
• If SSH tunneling is involved, configure SSH keepalives too
• Regularly timed disconnects may point to a firewall or other network device rather than to MySQL itself
• Choose timeout values that balance convenience with resource usage and operational policy