标量函数导致逐行调用和上下文切换，使百万行查询性能骤降；优化器视其为黑盒，抑制并行、降级索引查找；应移除函数，改用join、预计算或计算列优化。
标量函数导致逐行调用和上下文切换
数据库引擎无法将标量函数（如 dbo.GetContainerTEU）下推到扫描阶段，只能在结果集每行生成后单独调用一次。这意味着：对 100 万行数据，函数就被执行 100 万次；每次调用都涉及 SQL 执行环境与函数运行环境之间的上下文切换，带来显著 CPU 开销；参数传递、返回值封装还会增加内存负担。
优化器把函数当“黑盒”，无法生成高效执行计划
SQL Server 或 MySQL 的查询优化器无法预估标量函数的计算成本、返回行数或是否可并行化，只能保守地选择串行执行路径。常见后果包括：
- 执行计划中出现
Compute Scalar或大量Table Spool节点 - 本可走索引查找（
seek）的 JOIN 或 WHERE 条件被迫降级为扫描（scan） - 并行度被抑制，即使服务器有多核也只用单线程处理
嵌套视图 + 标量函数 = 性能雪崩
当视图定义里已含 GROUP BY 或 DISTINCT，再叠加标量函数，优化器几乎必然物化中间结果——也就是先算完整个视图输出，再对每一行调用函数。这种组合会触发：
- 临时表写入/读取（
Using temporary/Materialize） - 重复计算（例如同一
JobID在子查询中多次出现，函数被反复调用） - WHERE 条件无法下推至基表，导致全表扫描后再过滤
替代方案不是“改写函数”，而是绕开函数
不要试图优化标量函数本身（比如加缓存或改成内联表值函数），真正有效的做法是把它从 SELECT 列表里移除：
- 把函数逻辑直接展开为 JOIN 子查询（如用
LEFT JOIN oxContainer ... ON ta.JobID = job.JobID替代dbo.GetContainerTEU(job.JobID)） - 提前物化结果：用存储过程+临时表/持久表预计算汇率、TEU 等派生值，查询时直连该表
- 改用计算列（
AS (SUM(...)) PERSISTED）或视图内联聚合，让优化器有机会重排执行顺序
最隐蔽的坑是：即使函数逻辑只有一行乘法，百万级调用仍会让查询从秒级退化到分钟级——这不是数据库“不够快”，而是执行模型根本不适配标量函数的使用方式。
