标量udf强制查询串行执行是数据库引擎设计使然；sql server中只要视图含标量udf即禁用并行，postgresql则取决于函数的parallel属性（unsafe/restricted/safe），内联逻辑可恢复并行因消除了执行上下文隔离限制。
视图里只要出现标量自定义函数，整个查询就强制串行执行，根本跑不起来并行计划。
SQL Server 中标量 UDF 直接禁用并行
哪怕你只在视图的 SELECT 列表里写了一个 dbo.FormatPhone(number)，SQL Server 优化器在编译阶段就会标记该查询“不可并行”。OPTION (MAXDOP 0) 完全无效，执行计划里连一个 Parallelism 算子都不会出现。
- 不是配置没开，是引擎设计如此：标量 UDF 每次调用都有上下文切换、参数序列化、返回值反序列化等固定开销，数据库无法保证多线程并发调用时的结果一致性或资源安全
-
SCHEMABINDING或WITH RETURNS NULL ON NULL INPUT都不改变这一限制 - 只有内联表值函数（
ITVF）能参与并行，因为它会被展开成 SQL 片段，计算可下推到各 worker 进程中独立完成
PostgreSQL 的 PARALLEL 属性决定是否阻断并行
PostgreSQL 不像 SQL Server 那样一刀切，但函数的 PARALLEL 属性才是关键：
-
PARALLEL UNSAFE（默认）：禁止任何并行上下文调用 → 视图查询必然串行 -
PARALLEL RESTRICTED：函数只能在 leader 进程中执行 → 并行扫描仍可发生，但函数计算部分被串行化，成为瓶颈点 -
PARALLEL SAFE：真正支持并行，但要求函数不访问临时表、不修改 session 状态、不调用 UNSAFE 函数 - 查当前函数属性：
SELECT proname, provolatile, parallel FROM pg_proc WHERE proname = 'your_func';
为什么把函数逻辑直接写进视图 SQL 就能恢复并行？
因为并行障碍本质是“执行上下文隔离”——数据库怕多个 worker 同时进函数体出问题。一旦你把 dbo.CalcTax(@amt) 拆成 @amt * 0.08 + CASE WHEN @amt > 10000 THEN 200 ELSE 0 END，优化器就能把它当成普通表达式，分发到各并行分支里各自算。
- SQL Server 2019+ 的“标量 UDF 内联”功能（需兼容级别 150+）只对极简函数生效，含
WHILE、SELECT子查询、临时表的函数一律不内联 - PostgreSQL 没有自动内联机制，必须手动重写或改用
LATERAL JOIN+ITVF - 别指望
sp_refreshsqlmodule或重建视图来“修复”，它只刷新元数据绑定，不改变函数本身的并行能力
最常被忽略的一点：即使函数被标记为 PARALLEL SAFE，如果它内部调用了另一个 UNSAFE 函数，整个链路依然退化为串行——这种隐式依赖很难从外表看出来，得逐层检查 pg_proc。
