This section describes aspects of how the MySQL server manages client connections.
The server is capable of listening for client connections on multiple network interfaces. Connection manager threads handle client connection requests on the network interfaces that the server listens to:
On all platforms, one manager thread handles TCP/IP connection requests.
On Unix, the same manager thread also handles Unix socket file connection requests.
On Windows, one manager thread handles shared-memory connection requests, and another handles named-pipe connection requests.
On all platforms, an additional network interface may be enabled to accept administrative TCP/IP connection requests. This interface can use the manager thread that handles “ordinary” TCP/IP requests, or a separate thread.
The server does not create threads to handle interfaces that it does not listen to. For example, a Windows server that does not have support for named-pipe connections enabled does not create a thread to handle them.
Individual server plugins or components may implement their own connection interface:
X Plugin enables MySQL Server to communicate with clients using X Protocol. See Section 20.5, “X Plugin”.
Connection manager threads associate each client connection with a thread dedicated to it that handles authentication and request processing for that connection. Manager threads create a new thread when necessary but try to avoid doing so by consulting the thread cache first to see whether it contains a thread that can be used for the connection. When a connection ends, its thread is returned to the thread cache if the cache is not full.
In this connection thread model, there are as many threads as there are clients currently connected, which has some disadvantages when server workload must scale to handle large numbers of connections. For example, thread creation and disposal becomes expensive. Also, each thread requires server and kernel resources, such as stack space. To accommodate a large number of simultaneous connections, the stack size per thread must be kept small, leading to a situation where it is either too small or the server consumes large amounts of memory. Exhaustion of other resources can occur as well, and scheduling overhead can become significant.
MySQL Enterprise Edition includes a thread pool plugin that provides an alternative thread-handling model designed to reduce overhead and improve performance. It implements a thread pool that increases server performance by efficiently managing statement execution threads for large numbers of client connections. See Section 5.6.3, “MySQL Enterprise Thread Pool”.
To control and monitor how the server manages threads that handle client connections, several system and status variables are relevant. (See Section 5.1.8, “Server System Variables”, and Section 5.1.10, “Server Status Variables”.)
thread_cache_sizesystem variable determines the thread cache size. By default, the server autosizes the value at startup, but it can be set explicitly to override this default. A value of 0 disables caching, which causes a thread to be set up for each new connection and disposed of when the connection terminates. To enable
Ninactive connection threads to be cached, set
Nat server startup or at runtime. A connection thread becomes inactive when the client connection with which it was associated terminates.
When the thread stack is too small, this limits the complexity of the SQL statements the server can handle, the recursion depth of stored procedures, and other memory-consuming actions. To set a stack size of
Nbytes for each thread, start the server with
To control the maximum number of clients the server permits to
connect simultaneously, set the
variable at server startup or at runtime. It may be necessary
if more clients attempt to connect simultaneously then the
server is configured to handle (see
Section B.4.2.6, “Too many connections”). If the server refuses
a connection because the
max_connections limit is
reached, it increments the
mysqld actually permits
+ 1 client connections. The extra connection is reserved for
use by accounts that have the
CONNECTION_ADMIN privilege (or
privilege). By granting the privilege to administrators and
not to normal users (who should not need it), an administrator
can connect to the server and use
PROCESSLIST to diagnose problems even if the maximum
number of unprivileged clients are connected. See
Section 18.104.22.168, “SHOW PROCESSLIST Statement”.
As of MySQL 8.0.14, the server also permits administrative connections on an administrative network interface, which you can set up using a dedicated IP address and port. See Section 22.214.171.124, “Administrative Connection Management”.
The Group Replication plugin interacts with MySQL Server using
internal sessions to perform SQL API operations. In releases
to MySQL 8.0.18, these sessions count towards the client
connections limit specified by the
max_connections server system
variable. In those releases, if the server has reached the
max_connections limit when
Group Replication is started or attempts to perform an
operation, the operation is unsuccessful and Group Replication
or the server itself might stop. From MySQL 8.0.19, Group
Replication's internal sessions are handled separately from
client connections, so they do not count towards the
max_connections limit and are
not refused if the server has reached this limit.
The maximum number of client connections MySQL supports (that
is, the maximum value to which
max_connections can be set)
depends on several factors:
The quality of the thread library on a given platform.
The amount of RAM available.
The amount of RAM is used for each connection.
The workload from each connection.
The desired response time.
The number of file descriptors available.
Linux or Solaris should be able to support at least 500 to 1000 simultaneous connections routinely and as many as 10,000 connections if you have many gigabytes of RAM available and the workload from each is low or the response time target undemanding.
increases the number of file descriptors that
mysqld requires. If the required number of
descriptors are not available, the server reduces the value of
max_connections. For comments
on file descriptor limits, see Section 126.96.36.199, “How MySQL Opens and Closes Tables”.
variable may be necessary, which may also require raising the
operating system limit on how many file descriptors can be
used by MySQL. Consult your operating system documentation to
determine whether it is possible to increase the limit and how
to do so. See also Section B.4.2.17, “File Not Found and Similar Errors”.