视图必须返回确定性结果，因UUID()每次调用生成不同值，违反SQL标准；MySQL直接报错，PostgreSQL禁止使用volatile函数；确定性是查询优化、物化视图、权限控制、主从同步等的基础保障。
SQL视图里调用 UUID() 会报错或结果不可靠
因为视图必须返回确定性（deterministic）结果，而 UUID() 每次执行都生成新值，违反 SQL 标准对视图的语义约束。MySQL 会直接拒绝创建含 UUID() 的视图（报错 ERROR 1351 (HY000): View's SELECT contains a prohibited construct），PostgreSQL 则在定义时就禁止使用 volatile 函数。
为什么确定性对视图这么关键
视图本质是预定义的查询逻辑，不是快照。数据库依赖其确定性做很多事：
- 查询重写优化（比如把外层 WHERE 下推到视图定义中）——若视图内有
UUID()，下推后语义就变了 - 物化视图刷新或一致性校验——无法比对“上次 UUID 值”和“这次 UUID 值”是否合理
- 权限控制与审计——非确定性表达式可能绕过行级安全策略（例如用
UUID()拼接条件逃逸过滤） - 复制与备库同步——主库执行一次
SELECT * FROM v得到某 UUID，从库重放视图定义时得到另一个，主从不一致
想在视图里“类 UUID”标识行？换思路
如果目标只是给结果集加唯一标记（比如调试、去重、前端渲染 key），可用确定性替代方案：
- 用
ROW_NUMBER() OVER (ORDER BY ...)—— 排序字段必须明确且稳定（避免用ORDER BY RAND()） - 拼接业务主键 + 常量前缀，如
CONCAT('v_', id)，前提是id本身确定且非空 - 用
MD5(CONCAT(col1, col2, ...))做确定性哈希（注意：输入列不能含NULL，否则整个哈希为NULL） - 绝对不要用
UUID_SHORT()或NEWID()（SQL Server）——它们同样是 non-deterministic
真需要每次查都生成新 UUID？别用视图
视图不是万能封装层。遇到这类需求，更合理的做法是：
- 改用存储过程或函数封装逻辑，显式接受调用上下文（比如传入
session_id或时间戳作为 salt） - 在应用层生成 UUID 后作为参数传入查询（例如
SELECT ..., ? AS request_id FROM ...） - 用临时表 +
INSERT ... SELECT UUID(), ...分两步处理，避开视图限制
最易被忽略的一点：哪怕你绕过语法检查（比如在 MySQL 中用函数包装器伪装成 deterministic），只要底层调用了 UUID()，就仍可能在查询缓存、并行执行或分区裁剪中引发未定义行为——确定性不是“看起来一样”，而是“在任何合法执行路径下都必然相同”。
