Introduction

SHOW STATUS LIKE 'Threads_connected' shows active (currently open) connections. SHOW STATUS LIKE 'Connections' shows the total cumulative count of connection attempts since the server started. These are two different metrics, and confusing them is one of the most common MySQL monitoring mistakes. If you need to know "how many clients are connected right now," the answer is Threads_connected. If you need "how many connections has this server handled since last restart," the answer is Connections.

The Key Status Variables

MySQL exposes several connection-related status variables. Here are the ones that matter most:

1SHOW STATUS WHERE Variable_name IN (
2    'Connections',
3    'Threads_connected',
4    'Threads_running',
5    'Max_used_connections',
6    'Aborted_connects',
7    'Aborted_clients'
8);

The distinction between Threads_connected and Threads_running is important. A connection can be open but idle, waiting for the application to send a query. Threads_connected counts all open connections (active + idle). Threads_running counts only those actively executing a statement.

Checking Current Connections

How Many Clients Are Connected Now

SHOW STATUS LIKE 'Threads_connected';

1+-------------------+-------+
2| Variable_name     | Value |
3+-------------------+-------+
4| Threads_connected | 42    |
5+-------------------+-------+

This tells you 42 client connections are currently open. Some may be actively querying, others may be idle.

How Many Are Actively Running Queries

SHOW STATUS LIKE 'Threads_running';

1+-----------------+-------+
2| Variable_name   | Value |
3+-----------------+-------+
4| Threads_running | 5     |
5+-----------------+-------+

Out of 42 connected clients, only 5 are executing a query at this moment. The other 37 are idle but holding open connections.

What Each Connection Is Doing

SHOW PROCESSLIST;

Or for the full query text:

SHOW FULL PROCESSLIST;

This lists every connected thread with its state, current query, and how long it has been in that state. It is the best way to identify long-running queries, sleeping connections, and locked threads.

For a more queryable format:

1SELECT id, user, host, db, command, time, state
2FROM information_schema.PROCESSLIST
3WHERE command != 'Sleep'
4ORDER BY time DESC;

This filters out sleeping (idle) connections and sorts by duration, showing the longest-running active queries first.

Connection Limits and Capacity

Check Your Maximum Allowed Connections

SHOW VARIABLES LIKE 'max_connections';

1+-----------------+-------+
2| Variable_name   | Value |
3+-----------------+-------+
4| max_connections | 151   |
5+-----------------+-------+

The default is 151. In production, this is almost always too low.

Check the High-Water Mark

SHOW STATUS LIKE 'Max_used_connections';

1+----------------------+-------+
2| Variable_name        | Value |
3+----------------------+-------+
4| Max_used_connections | 98    |
5+----------------------+-------+

This tells you the peak number of simultaneous connections since the last server restart. If this value is close to max_connections, you are at risk of hitting the connection limit.

Connection Utilization Percentage

A useful operational metric is how close you are to the limit:

1SELECT
2    (SELECT VARIABLE_VALUE FROM performance_schema.global_status
3     WHERE VARIABLE_NAME = 'Max_used_connections') AS peak_connections,
4    (SELECT VARIABLE_VALUE FROM performance_schema.global_variables
5     WHERE VARIABLE_NAME = 'max_connections') AS max_allowed,
6    ROUND(
7        (SELECT VARIABLE_VALUE FROM performance_schema.global_status
8         WHERE VARIABLE_NAME = 'Max_used_connections') /
9        (SELECT VARIABLE_VALUE FROM performance_schema.global_variables
10         WHERE VARIABLE_NAME = 'max_connections') * 100, 1
11    ) AS utilization_pct;

If utilization is consistently above 80%, increase max_connections or implement connection pooling.

Configuring max_connections

At Runtime (No Restart Required)

SET GLOBAL max_connections = 500;

This takes effect immediately but reverts on server restart.

In the Configuration File (Persistent)

# /etc/mysql/my.cnf or /etc/my.cnf
[mysqld]
max_connections = 500

After editing, restart MySQL or reload the configuration.

Sizing Considerations

Each connection consumes memory. The rough formula is:

Memory per connection = sort_buffer_size + read_buffer_size + join_buffer_size + thread_stack

With default settings, each connection uses roughly 1-10 MB depending on the query. Setting max_connections = 10000 on a server with 4 GB of RAM will eventually cause out-of-memory issues if those connections are all active.

Connection Pooling

Instead of raising max_connections indefinitely, use a connection pooler. The application maintains a pool of reusable connections, which keeps the total count manageable.

Example: HikariCP (Java)

1HikariConfig config = new HikariConfig();
2config.setJdbcUrl("jdbc:mysql://localhost:3306/mydb");
3config.setUsername("app_user");
4config.setPassword("secret");
5config.setMaximumPoolSize(20);
6config.setMinimumIdle(5);
7config.setIdleTimeout(300000); // 5 minutes
8
9HikariDataSource ds = new HikariDataSource(config);

Example: Connection Pool in Python

1from mysql.connector.pooling import MySQLConnectionPool
2
3pool = MySQLConnectionPool(
4    pool_name="mypool",
5    pool_size=10,
6    host="localhost",
7    database="mydb",
8    user="app_user",
9    password="secret"
10)
11
12conn = pool.get_connection()
13cursor = conn.cursor()
14cursor.execute("SELECT 1")
15cursor.close()
16conn.close()  # Returns to pool, does not actually close

Monitoring Connections Over Time

For ongoing monitoring, record these values periodically:

1-- Snapshot query for monitoring systems
2SELECT
3    NOW() AS sample_time,
4    (SELECT VARIABLE_VALUE FROM performance_schema.global_status
5     WHERE VARIABLE_NAME = 'Threads_connected') AS connected,
6    (SELECT VARIABLE_VALUE FROM performance_schema.global_status
7     WHERE VARIABLE_NAME = 'Threads_running') AS running,
8    (SELECT VARIABLE_VALUE FROM performance_schema.global_status
9     WHERE VARIABLE_NAME = 'Connections') AS total_since_start,
10    (SELECT VARIABLE_VALUE FROM performance_schema.global_status
11     WHERE VARIABLE_NAME = 'Aborted_connects') AS aborted;

Feed this into Grafana, Datadog, or any time-series monitoring system to track connection trends and catch issues before they become outages.

Common Pitfalls

Confusing Connections with Threads_connected. Connections is a cumulative counter since server start. It increases monotonically. Threads_connected is a live gauge of currently open connections. If someone asks "how many connections do we have," they almost certainly mean Threads_connected.

Setting max_connections too high without considering memory. Each connection reserves memory buffers. A server with 1000 active connections and default buffer sizes can consume several gigabytes of RAM for connections alone, leaving insufficient memory for the InnoDB buffer pool.

Not monitoring Aborted_connects. A high rate of aborted connections often indicates authentication failures, connection storms from misbehaving applications, or clients being rejected because max_connections was reached. This metric is easy to overlook but operationally important.

Ignoring idle connections. Applications that open connections without closing them inflate Threads_connected without doing useful work. Use wait_timeout to automatically close idle connections after a configurable period (default is 28800 seconds, which is 8 hours).

Using SHOW PROCESSLIST instead of information_schema.PROCESSLIST for programmatic access. SHOW PROCESSLIST truncates query text to 100 characters and is harder to filter. The information_schema version gives you the full query and can be filtered with standard SQL WHERE clauses.

Summary

Threads_connected is the metric for currently open connections. Connections is the total cumulative count since server start. Threads_running shows how many of those connections are actively executing queries. Monitor Max_used_connections relative to max_connections to detect capacity issues before they cause connection rejections. Use connection pooling to keep the connection count manageable, and configure wait_timeout to clean up idle connections automatically. For production monitoring, track these values over time rather than checking them ad hoc.