The MySQL server creates the following threads:
One thread manages TCP/IP file connection requests and creates a new dedicated thread to handle the authentication and SQL statement processing for each connection. (On Unix, this thread also manages Unix socket file connection requests.) On Windows, a similar thread manages shared-memory connection requests, and on Windows NT-based systems, a thread manages named-pipe connection requests. Every client connection has its own thread, although the manager threads try to avoid creating threads by consulting the thread cache first to see whether a cached thread can be used for a new connection.
On Windows NT, there is a named pipe handler thread that does the same work as the TCP/IP connection thread on named pipe connect requests.
On a master replication server, slave server connections are 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.
The 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.
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
Each table for which
statements are issued gets its own thread.
If the event scheduler is active, there is one thread for the scheduler, and a thread for each event currently running.
mysqladmin processlist only shows the
INSERT DELAYED, replication
threads, and event threads.