必须加确定性声明，否则视图创建直接失败；SQL Server需WITH SCHEMABINDING，PostgreSQL需IMMUTABLE/STABLE，MySQL需DETERMINISTIC或READS SQL DATA，且均禁止非确定性函数、副作用操作及WHERE中调用。
必须加确定性声明，否则视图创建直接失败——这不是警告，是硬性拦截。
SQL Server：不加 WITH SCHEMABINDING 就报 Msg 4512
视图引用标量函数时，SQL Server 强制要求函数定义里带 WITH SCHEMABINDING。漏掉它，哪怕函数语法完全正确，CREATE VIEW 或 ALTER VIEW 都会立刻抛出 Msg 4512, Level 16 错误。
- 这个绑定不是可选项：它把函数和所依赖的表/列锁死，防止底层结构变更导致视图逻辑错乱
- 函数体里不能出现
#temp临时表、@table表变量、EXEC或sp_executesql - 禁用所有非确定性系统函数：
GETDATE()、NEWID()、RAND()、CONNECTION_ID()等一概不行 - 调用时必须用两段式名称：
dbo.format_phone(col)，写成format_phone(col)会找不到函数
PostgreSQL：函数必须标记为 IMMUTABLE 或 STABLE
PostgreSQL 对函数“稳定性”有明确分级，视图只接受 IMMUTABLE（最安全）或 STABLE（单次查询内一致）。用默认的 VOLATILE 会直接拒绝创建视图，报错：ERROR: cannot use function ... in view definition。
-
IMMUTABLE：相同输入永远返回相同输出，适合字符串处理、数学计算等纯逻辑 -
STABLE：允许读取当前时间（如CURRENT_DATE），但禁止写操作；在视图中可用，但部分查询优化器可能无法下推条件 - 检查当前函数属性：
SELECT proname, provolatile FROM pg_proc WHERE proname = 'format_phone'; - 修改函数需先
DROP再重建，不能用ALTER FUNCTION ... IMMUTABLE
MySQL 8.0+：必须显式声明 DETERMINISTIC 或 READS SQL DATA
MySQL 把“确定性”当作视图合法性门槛。没声明就用函数，CREATE VIEW 直接失败：ERROR 1351 (HY000): View's SELECT contains a function that is not allowed。
-
DETERMINISTIC是最稳妥的选择，尤其用于常量封装（如租户 ID、环境标识） -
READS SQL DATA适用于需要查配置表的场景，但查询本身也得是确定性的（比如SELECT value FROM sys_config WHERE name = 'tenant_id'） - 隐式类型转换可能被判定为非确定性：函数参数是
VARCHAR(10)，传入字段却是TEXT，某些版本会静默转空字符串 - 权限上，调用者需对函数有
EXECUTE权限，且函数名必须带 schema 前缀（如utils.get_tenant_id()）
WHERE 条件里调用函数是性能黑洞，别碰
视图中函数调用本身不报错，但一旦放在 WHERE 子句里，就会触发逐行计算，索引完全失效。这不是慢一点的问题，是数据量稍大就卡死。
- 例如：
SELECT * FROM user_view WHERE format_phone(phone) = '(123) 456-7890'—— 全表扫描不可避免 - 替代方案优先考虑计算列（SQL Server / MySQL 5.7+）或物化表达式（PostgreSQL 12+ 的生成列）
- 如果必须过滤，把函数逻辑内联到视图定义里，而不是在外部查询中调用
- 多语句表值函数（TVF）和内联 TVF 都不能在视图中调用，只有标量函数被允许
最容易被忽略的是类型匹配和权限上下文：函数参数类型和视图字段类型差一个字节，可能静默变 NULL；schema 没写全，开发库能跑，上线就报找不到对象；IMMUTABLE 函数里不小心用了 CURRENT_SETTING('app.tenant')，而该设置未标记为 USERSET，视图就编译不过。这些都不是语法错误，而是运行时或部署期才暴露的坑。
