ProxySQL以多线程的daemon运行，每个模块使用一个或多个线程去执行。

下面是正常运行时使用的线程列表：

该线程只负责引导启动核心模块以及启动其它核心线程。

该线程负责以下几件事：

• 初始化并引导启动Admin接口。
• 从磁盘数据库或配置文件中加载配置，为ProxySQL的运行提供环境。
• 如果启用了HTTP server(见下文)，它可以启动http服务来处理web UI。
• 如果启用了Cluster threads(见下文)，它可以配置Cluster模块。
• 它会启动一个监听者，让其负责监听并接受到Admin接口的新连接，并为每个这样的连接创建一个新线程。

mysql-threads线程负责处理MySQL流量，包括所有来自客户端的连接以及所有到后端服务器节点的连接。也就是：用少量线程处理任意多数量的连接。

MySQL workers线程在相同的端口上进行监听。当新客户端发起连接请求，其中一个MySQL worker线程将成功接受该连接，并创建一个MySQL会话(session)：客户端和会话绑定在该worker线程上，直到连接断开。换句话说，在断开连接之前，某客户端的所有连接总是被同一个worker线程处理。

这些线程其实就是空闲线程(idle threads)。

如果proxysql使用--idle-threads选项启动，每个worker线程都会伴随启动一个auxiliary线程。每个worker线程以及它的auxiliary线程一起工作：第一个线程处理活动的连接，并将所有的空闲连接派遣到第二个线程上，但第二个线程只要等待到了发生在空闲连接上的一个事件(或超时)，就会将连接还给第一个线程。

当活动的客户端连接数量远少于空闲客户端连接数量时，强烈建议使用"idle threads"。这使得ProxySQL可以处理几十万个连接(测试时是100W个连接)。

ProxySQL内置了一个基于limicrohttpd的HTTP server。通过MHD_USE_INTERNAL_POLLING_THREAD来配置它，可潜在地使用多线程。

ProxySQL集群中的每个ProxySQL节点都会启动一个专门的线程负责和对端通信(译注：每两两节点之间都启动一个集群线程)。随着ProxySQL节点的增加、移除，这类线程的数量也会随之动态增、减。

该线程扮演的是垃圾收集器，回收查询缓存。通过垃圾收集器，可保证在客户端等待响应的过程中绝不会回收缓存。

如果启用了ClickHouse(编译时加入了ClickHouse的支持，且proxysql使用--clickhouse-server选项启动)，那么该线程负责如下几件事：

• 初始化ClickHouse模块。
• 启动一个监听者，负责监听并接收想要访问ClickHouse的新连接，并为每个连接创建一个新的线程。

如果启用了SQLite3 Server(proxysql使用--sqlite3-server选项启动)，那么该线程负责以下几件事：

• 初始化SQLite3 Server模块。
• 启动一个监听者，负责监听并接收想要访问内置的SQLite3 Server的新连接，并未每个这样的连接创建一个新的线程。

Monitor模块会启动多个线程。 在ProxySQL 1.4.X中，Monitor模块启动的线程包括：

• 一个主线程(main thread)负责为每个监控类别启动一个线程，总共5个类别，如下：
• 一个负责安排连接检查的线程。
• 一个负责安排ping检查的线程。
• 一个负责安排只读(read-only)检查的线程(译注：具备read_only=1的都是slave)。
• 一个负责安排复制延迟检查的线程(replication lag check，即检查某从节点是否拖后腿了)。
• 一个负责组复制监控的线程。
• 一个线程池(初始值为mysql-threads的两倍)。

线程池负责执行所有的检查任务，并通过以上各调度线程来监控调度情况。线程池会基于监控队列中待检查的数量多少而自动增长、收缩。基于检查的结果，会使用相同的线程对结果进行处理，例如避开一个节点、重新配置一个主机组。

上面列出的线程中，各自所使用的CPU差别很大。

一般来说，MySQL worker线程是最繁忙的线程，它们的CPU使用率最多。

尽管其它的线程CPU使用率很低，但当ProxySQL处理几十万个请求时，Monitor模块会急剧增加Monitor线程池的大小，从而霸占对CPU的使用。