能调用，但只限于确定性标量函数，且必须满足数据库的稳定性与权限约束；表值函数、含now()或newid()的函数、未声明immutable/with schemabinding的函数一律禁止在视图中使用。
能调用，但只限于确定性标量函数，且必须满足数据库的稳定性与权限约束；表值函数、含NOW()或NEWID()的函数、未声明IMMUTABLE/ WITH SCHEMABINDING的函数，一律禁止在视图中使用。
SQL Server 视图里调用标量函数要加 WITH SCHEMABINDING
不加会编译失败，或者后续查询因绑定失效而报错Invalid object name。这不是可选项，是硬性要求。
-
WITH SCHEMABINDING强制函数依赖的对象（如表、列）不能被删改，保证视图元数据稳定 - 函数体内不能引用临时表、表变量、动态SQL（如
EXEC或sp_executesql） - 返回类型必须明确，不能是
text、ntext、image、timestamp或table - 若函数引用了其他 schema 下的对象（如
utils.format_phone），调用时必须显式写全名，否则视图创建时报Cannot find the function
PostgreSQL 视图中函数必须标记为 IMMUTABLE 或 STABLE
默认创建的函数是VOLATILE，视图编译直接拒绝——哪怕函数逻辑本身没副作用，也必须显式声明。
-
IMMUTABLE：相同输入必得相同输出，适合格式化、计算类逻辑（如format_phone） -
STABLE：单次查询内结果一致，允许读取当前 session 状态（如CURRENT_USER），但不能修改数据 -
VOLATILE函数（如含RANDOM()、NOW()）无法用于视图，即使只出现在SELECT列表中也会被拒 - 用
SELECT proname, provolatile FROM pg_proc WHERE proname = 'your_func'确认当前属性，改用ALTER FUNCTION ... IMMUTABLE修正
MySQL 8.0+ 视图调用函数需避开动态 SQL 和隐式类型转换
MySQL 对函数“确定性”的校验较松，但实际运行时容易静默失败：字段类型和函数参数类型稍有不匹配，就返回NULL而非报错。
- 函数定义必须带
READS SQL DATA或NO SQL特性，MODIFIES SQL DATA会被视图拒绝 - 避免在函数里用未声明变量（如漏写
DECLARE v_result VARCHAR(50)），否则视图首次查询可能卡住或返回空 - 调用时若传入
INT字段给期望VARCHAR的参数，某些版本会转成空字符串，而不是报类型错误 -
DELIMITER切换必须严格配对，否则视图创建时提示ERROR 1064，不是函数本身问题，而是语法解析中断
为什么 WHERE 中调用函数会导致性能雪崩
不是函数写得不好，而是数据库根本没法优化：函数调用发生在每一行上，无法下推到存储引擎，索引完全失效。
- 写成
WHERE format_phone(phone) = '(123) 456-7890'→ 全表扫描 + 每行执行一次函数 - 正确做法是把脱敏逻辑前置：建计算列
phone_masked AS (format_phone(phone)) PERSISTED，再在该列上建索引 - 若必须动态计算，改用
LATERAL JOIN（PostgreSQL/SQL Server 2019+）或内联表值函数（ITVF），让优化器有机会重写执行计划 - 别信“刷新视图就能提速”——
sp_refreshsqlmodule只更新元数据绑定，不改变函数逐行执行的本质
最容易被忽略的是并行性：只要视图定义里出现标量函数，SQL Server 就彻底禁用并行，PostgreSQL 则取决于PARALLEL属性是否为SAFE；手动展开函数逻辑，比调优函数本身更有效。
