MySQL Capacity Planning

MySQL capacity problems can look similar but need different fixes. A connection limit, a per-account cap, a full tablespace, and lock memory exhaustion are separate constraints. Identify which resource is exhausted before raising a server limit or removing data.

Plan the global connection pool

Start with the active connection settings, current usage, server high-water mark, and connection-refusal counter:

SHOW GLOBAL STATUS
WHERE Variable_name IN (
  'Threads_connected',
  'Max_used_connections',
  'Connection_errors_max_connections'
);

SHOW GLOBAL VARIABLES
WHERE Variable_name IN ('max_connections', 'max_user_connections', 'open_files_limit');

For each independently running application pool, calculate replicas × maximum connections per pool. Add workers, scheduled jobs, migration tools, and other services that connect to the same server. Compare that total with max_connections after accounting for connections used by other workloads, and leave headroom for deployments and bursts. Max_used_connections is the server’s simultaneous-connection high-water mark since startup, but FLUSH STATUS resets it to current use. Connection_errors_max_connections counts attempts refused at the global limit; compare it before and after an incident to confirm refusals in that interval. FLUSH STATUS can also reset global status counters, so account for resets when interpreting these values. The server’s effective max_connections can also be constrained by open_files_limit; check the active values in the MySQL system-variable reference, status-variable reference, and FLUSH STATUS documentation. MySQL reserves one extra connection for an account with CONNECTION_ADMIN (or deprecated SUPER) so an administrator can recover; do not count it as application capacity. See connection interfaces.

Use the MySQL connection-pool budget estimator with values from the target server. It runs locally and does not connect to MySQL. For the recovery path when ordinary connection slots are exhausted, see MySQL Error 1040: Too Many Connections.

For a per-instance pool-sizing workflow that accounts for replicas, other workloads, deployment overlap, and load testing, see How to Size a MySQL Connection Pool.

Check limits applied to one account

An application can fit within the global connection limit and still exceed a per-account limit. Compare the effective max_user_connections value for the connecting account with the total pool capacity across every service replica that uses that same user@host account. Individual account resource limits can override the global default; see MySQL’s account resource limit documentation. Also see MySQL Error 1203: Too Many User Connections and Error 1226: User Resource Limit Reached.

Use the MySQL account connection-budget estimator to compare pools sharing one account with its effective simultaneous-connection cap.

Consider server-side thread scheduling

MySQL Community 26.7 adds the Thread Pool plugin for workloads with high concurrent query execution. It manages server-side execution threads; it does not replace an application connection pool or increase max_connections. See how to enable and measure the MySQL 26.7 Thread Pool on Debian 13 before considering it for a measured concurrency bottleneck.

Separate connections from storage and lock capacity

• Error 1114, “The table is full”: check free disk space, the affected storage engine, and the relevant table or tablespace limit. Start with MySQL Error 1114 troubleshooting.
• Error 1206, “Lock table full”: InnoDB needs memory to track transaction locks. Review transaction size and row access patterns; this is not a disk-space or max_connections setting. See MySQL Error 1206 troubleshooting.

Changing max_connections does not solve storage exhaustion or lock-memory pressure. For the full code and message index, browse MySQL Error Troubleshooting. For other local browser-based diagnostics, visit SQL and Database Tools.