SQL Server视图调用标量函数必须加WITH SCHEMABINDING，否则报错Msg 4512；它强制绑定依赖对象并为确定性优化提供前提，但函数含GETDATE()等非确定性元素仍会失败。
SQL Server 视图里调用标量函数必须加 WITH SCHEMABINDING
不加会直接报错 Msg 4512，不是语法问题，是 SQL Server 的强制约束。它要求函数和所依赖的表/列结构绑定，防止底层改名或删列后视图逻辑失效。但更关键的是，WITH SCHEMABINDING 是让函数“有机会”被优化器识别为确定性（deterministic）的前提——虽然它本身不保证性能，但没它连入场券都没有。
常见踩坑点：
- 函数体里用了
GETDATE()、NEWID()或临时表 → 即使加了WITH SCHEMABINDING，SQL Server 也会拒绝创建 - 参数类型和视图字段类型不匹配，比如视图字段是
VARCHAR(50)，函数参数定义为CHAR(10)→ 可能静默截断或转空字符串 - 函数名没带 schema 前缀，如写成
format_phone(col)而不是dbo.format_phone(col)→ 视图编译时可能找不到，尤其在search_path不一致的环境
PostgreSQL 视图中函数必须声明为 IMMUTABLE 才安全
标记为 STABLE 虽然允许建视图，但一旦函数里有子查询或引用了其他表，优化器就无法下推 WHERE 条件，实际效果和标量函数一样拖慢查询。只有 IMMUTABLE 才真正表示“输入不变，输出绝对不变”，比如纯字符串拼接、数学运算、正则匹配等。
验证方式很简单：SELECT proname, provolatile FROM pg_proc WHERE proname = 'your_func_name'; 如果返回 v（volatile）或 s（stable），就不能放心用在视图里。
容易忽略的细节：
-
IMMUTABLE函数里不能调用任何 SQL 查询，哪怕只是SELECT 1；也不能用CURRENT_DATE这类看似稳定的系统函数 - MySQL 8.0+ 对应的是
DETERMINISTIC，但隐式类型转换（如把INT参数传给期望DECIMAL的函数）会被判定为非确定性，建视图直接失败
WHERE 条件里调用函数是性能黑洞，别碰
哪怕函数逻辑只有一行 UPPER(name)，写成 WHERE UPPER(name) = 'ABC' 就会让索引完全失效，触发全表扫描。这不是数据库笨，而是优化器根本无法反向推导“哪些原始 name 值经过 UPPER 后等于 'ABC'”。
替代方案比“修函数”更有效：
- 把函数逻辑拆进
JOIN：比如原dbo.GetCustomerType(id)，改用LEFT JOIN customer_types ct ON t.customer_id = ct.id - 高频简单转换（大小写、四舍五入、单位换算）直接写进视图 SQL，别封装成函数
- 对必须动态计算的场景，改用内联表值函数（ITVF），它会被展开成 SQL 片段，参与连接消除和索引选择
用 PERSISTED 计算列替代视图中的标量函数
这是最彻底的解法。比如视图里反复调用 dbo.F2Y(amount) 把分转成元，不如直接在基表上加一列：amount_yuan AS (amount / 100.0) PERSISTED，再在这列上建索引。这样既免去逐行函数调用开销，又能让 WHERE 和 JOIN 都走索引。
注意点：
-
PERSISTED列必须是确定性表达式，不能含GETDATE()、子查询等 - 如果原表数据量大，添加
PERSISTED列会锁表并触发全量计算，建议在低峰期操作 - PostgreSQL 没有
PERSISTED，但可用生成列（GENERATED ALWAYS AS ... STORED）达到同样效果
真正卡住性能的往往不是函数本身多复杂，而是它出现在视图的 SELECT 列表或 WHERE 子句里——这时候它就从“一次定义、多次复用”的便利工具，变成了每行必跑、无法跳过的执行枷锁。绕过它，比优化它更值得优先尝试。
