MySQL单次查询默认不利用多核CPU，因其设计将“一次SELECT”视为单线程逻辑单元；需同时启用parallel_query=ON、parallel_threads_limit≥2、innodb_parallel_read_threads≥parallel_threads_limit−1三个参数，并满足无索引全表扫描、无聚合/LIMIT/ORDER BY等严苛条件，且仅EXPLAIN FORMAT=TREE显示“Parallel scan”才真正生效。
MySQL单次查询默认不利用多核CPU，不是因为技术做不到，而是设计上刻意限制——它把“一次SELECT”当作一个逻辑单元，由单个线程串行执行。想让单条查询跑多核，必须满足极窄的条件并显式开启实验性功能。
为什么 EXPLAIN 看不到 Parallel scan，但实际没并行？
EXPLAIN（包括 FORMAT=JSON）根本不会显示并行信息；只有 EXPLAIN FORMAT=TREE 在最外层节点出现 Parallel scan 才算真正触发。常见误判包括：
- 看到
innodb_parallel_read_threads = 4就以为开了并行——其实没设parallel_query = ON，这个值完全无效 - 用
EXPLAIN ANALYZE看到parallel_workers: 1——说明只用了主线程，没派生任何工作线程 - 执行中
SHOW PROCESSLIST没出现状态为parallel read thread的后台线程——等于没并行
哪些 SELECT 实际能走并行扫描？
必须同时满足全部条件，缺一不可：
- 表是普通 InnoDB 表（非分区、非临时、非 MyISAM/Memory）
- 执行计划最外层是全表扫描（
type = ALL），且WHERE条件无法命中任何索引（例如status列真没建索引） - 语句不含
LIMIT、ORDER BY、GROUP BY、DISTINCT、子查询、CTE、窗口函数 -
Extra字段不能有Using index（即不能走覆盖索引） - 数据量足够大（通常 > 百万行），且未被
innodb_buffer_pool_size完全缓存
反例：SELECT COUNT(*) FROM t（聚合强制单线程）、SELECT * FROM t WHERE id = 123（走索引查找）、SELECT * FROM t LIMIT 10（带 LIMIT 直接禁用）。
必须设对的三个参数，少一个都白搭
MySQL 8.0.30+ 的并行查询是实验性功能，三者缺一不可：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
SET GLOBAL parallel_query = ON：全局开关，默认 OFF；不设这个，其他参数全失效 -
SET GLOBAL parallel_threads_limit = 3：单查询最多用几个线程（含主线程），建议 2–4；设成 CPU 核数反而因调度开销拖慢 -
SET GLOBAL innodb_parallel_read_threads = 2：InnoDB 层并行读线程数，必须 ≥parallel_threads_limit - 1
注意：innodb_parallel_read_threads 单独设为 4 是无效的——没有 parallel_query = ON，它只影响极少数底层物理读场景，和用户 SQL 并行无关。
比单查询并行更靠谱的多核利用方式
对绝大多数 OLTP 或混合负载，盲目开并行查询收益极低，反而增加内存与锁竞争。真正释放多核能力的常规做法是：
- 调高
innodb_read_io_threads和innodb_write_io_threads（如设为 8），尤其对 SSD 有效 - 合理设置
innodb_thread_concurrency（建议 CPU 核数的 1.5–2 倍），避免线程争抢 - 增大
thread_cache_size，减少短连接频繁创建/销毁线程的开销 - 操作系统层面禁用 NUMA 绑定或使用
numactl --interleave=all启动 mysqld，避免内存访问不均
并行查询不是“设个参数就自动变快”的通用加速器，它只在极少数无索引、无聚合、无 LIMIT 的大表全扫场景下才可能生效；而多查询并发、I/O 线程优化、连接复用这些手段，在真实业务中覆盖更广、收益更稳。
