MySQL 8.0 的 COUNT(*) 并行扫描几乎总失效，因其仅在无索引全表扫描、无 GROUP BY/LIMIT/ORDER BY/DISTINCT、普通 InnoDB 表、数据量超300万且未被缓冲池全量缓存时才可能触发；一旦含 WHERE 条件或索引可用，即退化为单线程。

MySQL 8.0 的 COUNT(*) 并行扫描几乎总失效

不是配置错了，是 MySQL 8.0 的并行聚合能力本身极其受限：COUNT(*)、SUM() 等聚合函数出现在最外层时，优化器会插入 stream_aggregate 节点，导致扫描被包裹在子节点中，EXPLAIN FORMAT=TREE 就看不到 Parallel scan。真正能触发并行的场景必须同时满足：type=ALL（无任何索引可用）、无 GROUP BY/LIMIT/ORDER BY/DISTINCT、表是普通 InnoDB 表、数据量 > 300 万行且未被缓冲池全量缓存。哪怕只加一个 WHERE status = 'active'，只要 status 有索引，就直接退化为索引查找，彻底绕过并行路径。

Oracle 中 GROUP BY 并行需显式启用且避开阻塞点

在 Oracle 里，GROUP BY 默认不会自动走并行，这一点很容易被忽略。想让它真正跑起来，通常得把三件事同时做到位：先用 ALTER TABLE t PARALLEL 4 给表设定并行度；再在执行语句里明确加上 SELECT /*+ PARALLEL(t, 4) USE_HASH_AGGREGATION */ ... 提示；同时还要保证统计信息是最新的，也就是执行过 DBMS_STATS.GATHER_TABLE_STATS。至于为什么明明配了却还是不生效，常见原因基本就这几类：查询里带了 ROWNUM 或 FOR UPDATE；GROUP BY 字段被函数包了一层，比如 UPPER(name)；字段里存在大量 NULL 值，导致哈希分组在重分布时失败；还有一种也很典型，就是会话没有启用并行 DML，这对 UPDATE 类的聚合更新尤其关键。

SQL Server 视图里调用标量 UDF 直接禁用并行

只要视图定义里带了标量用户定义函数，哪怕它只是出现在 SELECT 列表中，整个查询也会被直接锁死在串行执行上。这不是参数配置的问题，而是引擎本身的设计限制。去 sys.dm_exec_query_plan 里看一眼，如果找不到 Parallel="1"，基本就能确认并行已经被禁用了。真正能用的改写路径其实只有两条：要么依赖 /*+ INLINE */，前提是 SQL Server 2019+、兼容级别 150+，而且函数足够简单，系统才可能自动内联；要么更彻底一点，手动把函数逻辑摊平成纯 SQL 表达式，比如把 dbo.calc_tax(@amt) 直接改写成 @amt * 0.08 + CASE WHEN @amt > 10000 THEN 200 ELSE 0 END。至于重建视图，或者刷新元数据（sp_refreshsqlmodule），对这件事完全没有帮助。

PostgreSQL 并行聚合受函数 PARALLEL 属性严格约束

PostgreSQL 不像 Oracle 那样靠 hint 强制，而是由函数本身的 PARALLEL 属性决定：PARALLEL UNSAFE（默认）直接阻断并行；PARALLEL RESTRICTED 允许扫描并行但函数计算只能在 leader 进程执行；只有 PARALLEL SAFE 才真正支持 worker 并发调用。用 SELECT proname, provolatile, parallel FROM pg_proc WHERE proname = 'your_func' 查属性。最容易忽略的是：即使函数标记为 SAFE，若它内部调用了 UNSAFE 函数，整个链路仍退化为串行。

《夸克》非常好用的免费AI浏览器

下载APP查看