The MySQL server creates the following threads:
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, this manager thread also handles Unix socket file connection requests. On Windows, a manager thread handles shared-memory connection requests, and another handles named-pipe connection requests. 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.
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.
For information about tuning the parameters that control thread resources, see Section 188.8.131.52, “How MySQL Uses Threads for Client Connections”.
On a master replication server, connections from slave servers are handled like client connections: There is one thread per connected slave.
On a slave replication server, an I/O thread is started to connect to the master server and read updates from it. An SQL thread is started to apply updates read from the master. These two threads run independently and can be started and stopped independently.
A signal thread handles all signals. This thread also
normally handles alarms and calls
process_alarm() to force timeouts on
connections that have been idle too long.
InnoDB is used, there will be
additional read and write threads by default. The number of
these are controlled by the
parameters. See Section 14.2.14, “
InnoDB Startup Options and System Variables”.
If mysqld is compiled with
-DUSE_ALARM_THREAD, a dedicated thread that
handles alarms is created. This is only used on some systems
where there are problems with
or if you want to use the
code in your application without a dedicated signal handling
If the server is started with the
option, a dedicated thread is created to flush all tables
If the event scheduler is active, there is one thread for the scheduler, and a thread for each event currently running. See Section 19.4.1, “Event Scheduler Overview”.