第 27 章：Parallel Query

这是《MySQL 8.0 源码与内核实战》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 社区 MySQL 8.0 对并行查询的支持有限，聚集计算和多数单条 SELECT 仍以单线程执行为主。并行读取更多出现在发行版、HeatWave 或分析引擎中。本章重点是理解并行模型与瓶颈。

27.1 串行执行

one worker
  -> read rows
     -> filter
        -> aggregate
        -> sort
           -> return

瓶颈可能：

1. CPU 单核；
2. Buffer Pool latch；
3. B+Tree 并发；
4. IO；
5. 排序；
6. 网络发送；
7. 行解析。

27.2 并行扫描模型

coordinator
  -> split ranges / pages
     -> workers
        -> partial aggregation
           -> merge

适合：

1. 大范围扫描；
2. 少量复杂聚合；
3. 只读分析；
4. 数据分布均匀；
5. IO 能力充足。

不适合：

1. 点查；
2. 小结果集；
3. 强锁读；
4. 高并发 OLTP；
5. 更新和事务冲突明显。

27.3 并行聚合

SELECT status, COUNT(*), SUM(amount)
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY status;

模型：

workers compute partial results
  -> coordinator merge by group key

难点：

1. DISTINCT；
2. 窗口函数；
3. 排序语义；
4. 精度；
5. 分组倾斜；
6. 内存控制。

27.4 MySQL 生态差异

同一条 SQL 的并行行为不能跨实现假设。

27.5 观测

EXPLAIN ANALYZE SELECT ...;
SELECT * FROM performance_schema.threads WHERE type='foreground';
SHOW PROCESSLIST;

并行执行要观测：

1. worker 数；
2. 每个分区扫描行数；
3. merge 时间；
4. 内存；
5. p95/p99；
6. 对 OLTP 干扰。

27.6 生产判断

是否并行应考虑：

1. 查询频率；
2. 扫描量；
3. SLA；
4. CPU 水位；
5. IO 延迟；
6. 并发事务；
7. 缓存命中率；
8. 是否可路由分析库。

本章小结

社区 MySQL 8.0 不是通用 MPP 数据库，复杂分析应考虑专用链路。并行查询的收益来自大扫描和聚合，代价是 CPU、内存和调度干扰。

思考题

1. 哪些 OLTP 点查不适合并行？
2. 并行聚合如何合并部分结果？
3. 为什么 DISTINCT 和窗口函数更难并行？
4. 如何评估并行查询对在线事务的干扰？
5. 社区版与发行版能力为什么不能混为一谈？