MySQL 的服务端线程架构常常被误读为“单线程数据库”或者“每条 SQL 独占一个线程池”。真实情况是，MySQL 服务器层使用每连接一个线程（one-thread-per-connection）的模型来处理客户端请求，而存储引擎层如 InnoDB 又维护着一组独立的后台线程。要厘清 SQL 执行到底是单线程还是多线程，需要分别从连接处理、语句执行以及引擎内部三个层面来看。
一、服务器层的连接线程模型
当客户端通过 TCP 或者套接字连上 MySQL 时，服务端会从线程缓存里取一个线程，或者新建一个线程来专门服务这个连接。从连接建立到断开，这条连接上的所有 SQL 请求都由同一个线程依次处理。也就是说，对于单个连接而言，SQL 是串行执行的，不可能出现同连接内两条 SQL 真正并行跑的情况；但从全局看，不同连接分属不同线程，因此整个 MySQL 实例是多线程的。
可以用一条简单命令观察当前连接对应的线程编号：
-- 查看当前连接对应的 MySQL 线程 ID
SELECT CONNECTION_ID() AS conn_id,
CURRENT_USER() AS user_account;
-- 在另一个会话中查看所有活跃线程
SHOW PROCESSLIST;
上面的 SHOW PROCESSLIST 会列出每个连接线程的 ID、状态与正在执行的命令。如果看到几十个连接处于 Query 状态，就说明有几十个线程在同时处理 SQL，这显然不是单线程系统。不过要注意，这些线程是“每人守一个连接”，而不是“每人抢一条 SQL”。
这种模型的优点是实现简单、上下文隔离好；缺点是在海量短连接场景下，线程创建和销毁的系统调用开销会变得明显。MySQL 提供了 thread_cache_size 参数来缓存空闲线程，减少反复创建的成本。
二、单条 SQL 在默认配置下是串行执行
很多开发者关心“一条复杂 SQL 会不会被拆成多个线程并行算”。在官方社区版 MySQL 的默认参数下，一条 SQL 在单个连接线程内是串行执行的：解析、优化、扫描表、计算临时结果、返回，都由一个线程完成。即使表很大，也通常是单线程顺序扫，不会自动把不同分片交给不同 CPU 核心。
下面这段伪代码体现了单线程执行顺序的本质：
// 简化表示的 MySQL 连接线程处理逻辑
void handle_connection(THD* thd) {
while (thd->net_read_query()) { // 读一条 SQL
parse_sql(thd); // 解析
optimize(thd); // 生成执行计划
execute(thd); // 单线程执行，扫表与计算均在此完成
send_result(thd); // 返回结果
}
}
从代码逻辑可以看出，execute 阶段并没有把任务分发给线程池并行处理。因此，一条涉及大表 JOIN 的慢查询，在默认设置里只会占满一个 CPU 核心，其他核心可能处于空闲。若想让单条 SQL 利用多核，需要依赖 MySQL 8.0 提供的并行查询能力（如设置 parallel_degree 等，且受引擎与语句类型限制），或借助应用层分片查询再汇总。
此外，同一个连接内如果先发一条 SQL 再发另一条，第二条必须等第一条结束。这是因为连接线程一次只处理一个命令，这也是为什么在应用代码里不该在事务中穿插不必要的远程调用，以免长时间占用线程。
三、InnoDB 引擎的后台多线程
虽然用户 SQL 多由连接线程驱动，但 InnoDB 并不止有这些前台线程。它内部运行着 master thread、IO thread、purge thread、page cleaner thread 等后台线程，负责刷脏页、回收 undo、处理异步 IO 等。这些线程与“SQL 执行”不是同一概念，但它们直接影响 SQL 的吞吐和延迟。
例如，当一条 SQL 大量更新数据，脏页产生很快，page cleaner 线程若来不及刷盘，前台线程就可能在 checkpoint 时被迫等待。可通过如下语句查看 InnoDB 线程情况：
-- 查看 InnoDB 后台线程与 IO 状态 SHOW ENGINE INNODB STATUSG
输出中的 FILE I/O 段会列出多个 io thread，TRANSACTIONS 段能看到 purge 进度。理解这一点能避免一个常见误区：以为 SQL 慢纯粹是“执行线程少”，其实可能是后台刷脏页线程瓶颈拖累了前台。
在读写混合的高并发场景，适当调大 innodb_page_cleaners 与 innodb_purge_threads，往往比单纯加连接线程更有效，因为它们解决了资源回收的并行度问题。
四、线程池插件与高并发优化
企业版 MySQL 或部分发行版提供了线程池（thread pool）插件，用少量固定线程分组处理大量连接，避免每连接一线程带来的调度爆炸。它改变了“连接与线程一一对应”的默认关系，让多个连接复用一组 worker 线程，从而降低上下文切换。
开启方式通常为加载插件并设置相关变量：
-- 安装线程池插件（以企业版为例） INSTALL PLUGIN thread_pool SONAME 'thread_pool.so'; -- 设置线程池大小相关参数 SET GLOBAL thread_pool_size = 16; SET GLOBAL thread_pool_max_threads = 1000;
使用线程池后，不再是无限制地每连接建线程，而是把连接放进不同的 group，由 worker 线程按优先级处理。这对短查询高并发特别有用，但也可能让长事务占住 worker 导致饥饿，因此需配合最大执行时间等限制。
对于大多数使用社区版的用户，合理设置 thread_cache_size、减少长连接、使用连接池（如应用侧 HikariCP）也能在默认模型下取得不错效果，不一定非要换线程池插件。
五、总结与误区澄清
回到标题的问题：MySQL 中 SQL 执行既是多线程也是单线程，取决于观察层面。服务器用多线程服务多连接，但单连接内 SQL 串行；单条 SQL 默认单线程跑，引擎后台却有多个线程协同。把它简单说成“单线程数据库”忽略了连接并发，说成“全并行”又忽略了语句级串行。
实际调优时，应先通过 PROCESSLIST 确认瓶颈在连接数、单条语句还是后台线程，再针对性调整参数或改写 SQL。只有把连接模型、语句执行模型与引擎线程模型分开看，才能给出准确的性能诊断。