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.
InnoDBis used, there will be additional read and write threads by default. The number of these are controlled by the
innodb_write_io_threadsparameters. See Section 14.17, “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
sigwait()or if you want to use the
thr_alarm()code in your application without a dedicated signal handling thread.
If the server is started with the
--flush_time=option, a dedicated thread is created to flush all tables every
If the event scheduler is active, there is one thread for the scheduler, and a thread for each event currently running. See Section 20.4.1, “Event Scheduler Overview”.