SQL视图可成为语义层的物理载体，前提是命名体现业务含义、内嵌详细注释、禁止跨库JOIN、固化权限与行级过滤，并确保每条CREATE VIEW语句都承载完整指标定义。
SQL视图本身不是语义层，但它能成为语义层的物理载体——前提是设计时明确承载业务含义，而非仅封装技术逻辑。
视图命名必须体现业务指标或维度，不能照搬表名
很多人写 CREATE VIEW order_summary，但“summary”毫无业务上下文。别人看到这个视图，仍需翻源码猜它到底算的是“支付订单数”还是“下单未支付数”。
- 正确做法：用业务术语命名，比如
view_active_customer_count_by_month、view_gmv_excluding_refund - 命名中显式包含口径关键词，如
_excluding_refund、_by_first_order_date，避免后续被误用 - 避免缩写歧义，
view_cust_ltv不如view_customer_lifetime_value_rolling_12m清晰（长度换可维护性）
视图定义里必须内嵌业务注释和口径说明
数据库不支持在视图元数据里存业务定义，所以注释得写进 SQL 本身，且要能被下游工具（如 BI 工具、RAG 系统）提取。
- 在
CREATE VIEW语句开头加多行注释，例如：/* 【指标名称】月度活跃客户数（MAU） 【定义】当月至少完成一次支付的去重用户数（基于 user_pseudo_id） 【排除项】测试账号、退款订单不计入 【来源表】events_* + orders */ CREATE VIEW view_mau AS ...
- 不要只写“聚合用户数”，要写清楚“去重依据是哪个字段”“时间切片按 event_date 还是 order_created_at”
- BI 工具或 RAG 检索时，会扫描这些注释块作为语义锚点；没注释 = 无语义
禁止跨库/跨实例 JOIN，否则语义层无法迁移和复用
视图若引用 sales_db.orders 和 user_db.profile，就锁死了部署环境。一旦要做分库分表或迁云，整个视图链就断了。
- 所有 JOIN 必须发生在同一数据库实例内，且优先走数仓层已整合好的宽表（如
fct_orders、dim_customer） - 如果真要关联外部系统数据，用物化视图 + 定时同步，而不是实时跨库查询
- 上线前检查
SHOW CREATE VIEW xxx（MySQL）或\d+ view_name（PostgreSQL），确认没有出现跨 schema 引用
权限与行级过滤必须固化在视图定义中，不能靠应用层补
把 WHERE tenant_id = current_setting('app.tenant_id') 这类逻辑放在应用层，等于裸奔。连接池复用后 current_setting 可能残留旧值，导致租户数据泄露。
- PostgreSQL 视图必须加
WITH CHECK OPTION，强制拦截违反条件的写入（哪怕你只读） - MySQL 没有原生 CHECK OPTION，可用触发器模拟，或在视图注释里加
【RLS】tenant_id = ?标记，由中间件解析并注入参数 - 测试时直接用
SELECT * FROM view_tenant_orders验证是否返回空或全量——这是权限失效最快速的暴露方式
真正难的不是写视图，而是让每个 CREATE VIEW 语句都像一份微型指标字典：字段名、口径、依赖、权限、更新频率，全部压进那几十行 SQL 里。漏掉任何一项，下游就得靠人肉对齐，语义层就退化成又一层 SQL 垃圾。
