【面试直击：化零为整的推土机，OceanBase 里的并行执行 (PQ) 折叠时空之术】

导语

OceanBase 专属面试

在日常的在线交易（OLTP）系统中，我们总是希望 SQL 像狙击手一样：找准索引，0.1 毫秒击毙一行数据然后光速撤退。
但是，如果老板突然要在白天拉一份包含一百亿行交易记录的“双十一全链路销售大盘财务报表”呢？让一个可怜的 CPU 线程去一行行扫一百亿条记录做聚合，结果绝对是跑到天黑都出不来，甚至把系统的内存挤爆。
今天，“DBA面试君”就带你拆解 OceanBase 最强悍的 HTAP 底盘能力——**并行执行（Parallel Query, PQ）**。教你如何一键召唤出蚂蚁雄兵，把按小时计算的任务，拍扁进秒级阵列里！

👉 【OceanBase 面试情景对话】

Interview scenario dialogue

👨‍💻OceanBase 原厂资深技术专家 (考官)：“你好。我们知道 OceanBase 是一个同时支持在线交易处理 (OLTP) 和在线分析处理 (OLAP) 的 HTAP 头号国产数据库。在应对动辄扫描几亿行的报表或者跑批（Batch）聚合查询时，单线程串行计算是远远不够的。
请问：在 OceanBase 中，如果我们想极大地缩短一条复杂报表 SQL 的执行时间，最核心的原生手段是什么？在实操中，作为 DBA 你推荐用怎样的方式最优雅地开启并控制它？更重要的是，它有什么让你防不胜防的毒副作用（必须避坑的点）？”

😎DBA面试君 (候选人)：“专家您好！这也是我们在做大促盘点时最爱用、却也是最危险的一把核武器——**并行执行（PQ）。**
它的本质非常简单暴力：当一个庞大的全表扫描、巨量 GROUP BY 或者多表大 Hash Join 压下来时，优化器会把这一个宏大的任务，切分为多个互相独立的小执行流（DFO），然后立刻拉起几十个甚至上百个 Worker 线程，跨越物理机分布式地同时去啃这块硬骨头。
它最大的效果就八个字：以资源，换绝对时间。”

💡DBA面试君拆解：并行执行的“用与防”

🔥实战落子：“一把梭”最优雅的开火方式 (SQL Hint)

很多新手 DBA 喜欢去调系统全局的 ob_stmt_parallel_degree 等系统变量。但这极度危险！一旦全局默认开启高并发，极其容易让普通的业务连接瞬间把系统的线程池榨干。

🖤最标准、最高端的外科手术刀：SQL Hint
在实际生产运维中，我们几乎 100% 推荐让开发人员甚至报表 BI 系统，仅仅在需要跑大查询的 SQL 文本中间，强行插入一把钥匙：

在这条语句中，/*+ PARALLEL(8) */ 就是我们指定的并行度（DOP = Degree of Parallelism）。

这句话就是在命令 OB：“哪怕平时你都只派一个线程去跑，现在这个报表，请你砸给我8 个线程同算，立刻，马上！”

💥震撼的战果：折叠时空（HTAP 降维打击）

开启 PQ 后，你会在执行计划里（EXPLAIN）看到满屏的 EXCHANGE OUT、EXCHANGE IN 和 DFO 的字眼。这说明调度器已经把任务分发出去了。

🖤效果立竿见影：化小时为读秒
如果之前全表扫描 5 亿行需要 8 个小时。
当你打上 /*+ PARALLEL(128) */，它可能会把这 5 亿行劈成 128 份，均匀散布到集群后台三台高配置的 OBServer 机器上。每台机器拉起上百个空闲的 CPU 核心全速运转。
最后，各个线程把算好的局部 Sum 值通过网络 RPC 抛给发号施令的主节点（Coordinator）一汇总！原本 8 小时的报表业务，可能短短两三分钟内（甚至十几秒之内）就被几百个线程组成的“推土机群”暴力趟平出总结果！

⚔️面试高分防雷区：给 OLTP 喂了 PQ 的毒药，系统当场休克！

面试到这里其实刚刚拿了 60 分。高级架构师绝不只懂什么能用，更懂什么**万万不能用**。

避坑保命法则：PQ 极其昂贵的“启动费”
如果一个开发新手觉得“加上 `PARALLEL(16)` 就会变快 16 倍”，于是把它悄悄加在了登录页面的 `SELECT user_id FROM users WHERE username = 'admin'` 这种单行点查上，灾难就降临了。

为什么？因为开火是有代价的！
并行度 16，意味着系统必须先去向线程池请求分配 16 个线程，还要设置好它们之间复杂的内存网络通信（RPC）通道，还要切分任务块。这个准备工作（Overhead）可能就要耗费几毫秒甚至十几毫秒。
而那个走索引的单行点查，本来单线程跑，0.1 毫秒就结束了！
强行并行，不仅让这条本来 0.1 毫秒的 SQL 慢了 100 倍（花了 10.1 毫秒去协调调度还什么都没算），更致命的是，如果并发一高，每秒有一千个登录请求都来索要 16 个后台线程，系统的百万并发线程池会在 1 秒内被瞬间全部剥削抽干！整个数据库直接 `queue_time` （我们在前面讲过它）爆表，活活因为缺少可用空闲线程而当场暴毙休克！

结论总结：PQ 是一只只能被放归到荒野（大扫描、大聚合）上的猛虎，绝不能让它走在大街上（单点高频 OLTP）。

技术专家点评

“回答得非常通透！是一份满分的大厂实战答卷。
1. 点出了 PQ 是典型的 【以资源换时间】 这一本质哲学，证明你不迷信调优，而是明白守恒定律。
2. 给出了 【基于 SQL Hint 级别的控制】，这是目前运维人员容错率最高、对业务侵入性最小的推荐写法。
3. 能主动向考官抛出 【在 OLTP 场景下乱用 PQ 带来的调度开销与线程池抽干雪崩】 这个致命反例，把并行的正向与负向代价拆解得淋漓尽致。
很精彩，你随时可以入职接手大促护航了！”