SQL视图不支持参数化，子查询必须静态安全：禁止拼接和硬编码，避免NULL导致IN失效，禁用SELECT*，聚合需符合GROUP BY规则，递归逻辑应拆出CTE或封装为函数。
SQL视图里不能用参数化，所以子查询必须静态安全
视图（VIEW）本质是预定义的 SELECT 语句，数据库在创建时就固化了 SQL 文本，不支持运行时传参。这意味着你写进视图里的任何子查询，都必须从源头杜绝拼接、硬编码和隐式类型转换风险——没有 cursor.execute(sql, params) 这种兜底机制。
常见错误现象：视图定义中出现 f"SELECT ... WHERE status = '{user_status}'" 或 CONCAT('SELECT * FROM users WHERE role = ', @role)，这类写法在 CREATE VIEW 时可能语法通过，但一旦底层表结构或数据类型变化，就会在后续查询中报错或返回错值。
- 所有外部输入（比如用户角色、状态码、时间范围）不能以任何形式出现在视图定义中，必须由调用方在 SELECT 视图时用 WHERE 过滤
- 子查询若依赖常量，优先用枚举值或带 CHECK 约束的列，避免用字符串字面量如
'active'——万一拼错或大小写不一致，视图就静默失效 - 涉及日期计算的子查询（如
(SELECT MAX(login_time) FROM audit_log)），建议加WHERE action = 'login'显式限定，否则日志表混入其他 action 会导致结果漂移
WHERE 中的 IN 子查询在视图里极易因 NULL 失效
视图里写 user_id IN (SELECT user_id FROM team_members WHERE team_id = 101) 看似没问题，但只要 team_members.user_id 允许为 NULL，整个 IN 表达式对任意外层行都返回 FALSE（SQL 标准规定：1 IN (1, NULL) 结果是 UNKNOWN，等价于 FALSE）。
这不是 bug，是标准行为，但多数开发者没意识到它会让整行“消失”。尤其当视图被其他业务模块引用时，数据丢失很难定位。
- 改用
EXISTS替代IN：把条件移到子查询内部，显式关联外层字段，例如EXISTS (SELECT 1 FROM team_members WHERE team_members.user_id = t.id AND team_members.team_id = 101) -
SELECT 1比SELECT *更稳妥，明确告诉优化器只需判断存在性，避免字段增多导致计划退化 - 确保子查询中关联字段类型与外层严格一致，比如外层
t.id是BIGINT，子查询里的team_members.user_id也必须是BIGINT，否则隐式转换会绕过索引
派生表（FROM 中的子查询）必须显式命名且避免 SELECT *
视图里用 FROM (SELECT ... ) AS t 是常见做法，但容易忽略两个硬性约束：子查询必须有别名，且不能返回重复列名。更隐蔽的问题是 SELECT * —— 它会让视图脆弱得像纸糊的。
一旦源表新增字段，视图结构可能不变，但下游应用如果按旧字段顺序解析结果（比如用 row[2] 取第三个值），就会取错数据。PostgreSQL 甚至会在某些版本中直接拒绝含 SELECT * 的视图创建（除非加 WITH LOCAL CHECK OPTION）。
- 始终用明确字段列表替代
*，例如SELECT user_id, COUNT(*) AS order_cnt，而不是SELECT * - 别名用下划线分隔的短小名称（如
user_stats），避免用t、sub这类模糊缩写，方便后续维护者快速理解用途 - 若子查询含聚合（如
GROUP BY），确保SELECT列全部在GROUP BY中，否则 MySQL 8.0+ 会报错，SQLite 则可能返回不确定结果
递归权限继承必须拆出 CTE，不能塞进视图子查询
想在视图里实现“用户→角色→权限”的多层继承？别试图用三层嵌套子查询硬刚。视图不支持 WITH RECURSIVE 直接嵌套在子查询里（MySQL 完全不支持，SQL Server 要求 CTE 必须在最外层），强行写会导致语法错误或执行时栈溢出。
更麻烦的是，递归深度不可控——假设某用户继承链长达 50 层，而数据库默认递归限制是 100，看似够用；但并发查询时资源争抢可能导致实际深度被截断，权限就漏了。
- 正确做法：把递归逻辑单独建一个物化视图或临时表（如
user_effective_roles），每天凌晨用存储过程刷新一次 - 视图只负责关联这个预计算表，例如
JOIN user_effective_roles uer ON uer.user_id = u.id，彻底解耦动态逻辑与静态定义 - 若必须实时计算，改用函数封装递归 CTE（PostgreSQL 支持
CREATE FUNCTION返回SETOF），视图里调用该函数，而非把 CTE 塞进子查询
视图里的子查询不是“写完就能跑”，它卡在定义期就锁死了执行路径。最易被忽略的是：你以为的安全过滤（比如 WHERE status = 'active'），其实正悄悄让 NULL 数据穿透进来；而你信任的 SELECT *，可能下周就让下游服务崩在字段顺序上。
