视图应只封装稳定、可复用、无上下文依赖的计算逻辑，如COALESCE(sales_amt, 0)、DATE(order_time)、UPPER(user_name)；禁止封装业务筛选条件（如WHERE region = '华东'或stat_month = '2024-03'），须由上层查询动态下推，避免结果漂移与复用失效。
视图该封装什么计算逻辑
只封装稳定、可复用、无上下文依赖的计算，比如 COALESCE(sales_amt, 0)、DATE(order_time)、UPPER(user_name)。这些操作在所有报表里都一致，改一次，全链路生效。别把 WHERE region = '华东' 或 AND stat_month = '2024-03' 塞进视图——那是业务筛选，得留给上层查询动态下推。
常见错误现象：视图里写死时间范围或地区，导致别人查“华北”时必须重写视图，或查不到数据还查不出错；更糟的是，多个报表共用该视图后，有人悄悄改了 WHERE 条件，其他报表结果就静默漂移。
- 基础层（
base_order）只做单表清洗：去重、空值归一、字段重命名、类型强制转换 - 中间层（
dm_order_detail）才做 JOIN 和宽表补全：关联用户等级名、商品类目、区域编码等维度字段 - 带
rpt_前缀的视图是交付态，变更需评审；base_和dm_是资产层，加字段前必须grep -r 'base_order' .查全库引用
为什么不能在视图里用 SELECT *
SELECT * 会让视图结构不可控：上游表加字段，视图输出列就变；上游删字段，视图直接报错；JOIN 多张表时，* 还可能引发列名冲突（比如两张表都有 id），导致外层查询 SELECT id 报 “ambiguous column”。
正确做法是显式列出每一列，并重命名易歧义字段：
CREATE VIEW dm_order_detail AS SELECT o.order_id, o.user_id, COALESCE(o.amount, 0) AS amount, u.level_name AS user_level_name, p.category_name AS product_category FROM base_order o JOIN base_user u ON o.user_id = u.user_id JOIN base_product p ON o.product_id = p.product_id;
这样既防字段漂移，也方便下游知道“这列是谁给的、怎么算的”。
嵌套视图的性能陷阱在哪
视图不缓存结果，每次查询都展开执行原始 SQL。三层嵌套（rpt → dm → base）在 PostgreSQL 可能触发 MATERIALIZE 节点，实际执行变成先物化中间结果再 JOIN，I/O 暴涨；MySQL 默认用 TEMPTABLE 算法处理复杂子查询，性能比直接写 JOIN 差一个数量级。
验证方式很简单：
EXPLAIN SELECT * FROM rpt_monthly_sales WHERE stat_month = '2024-03';
重点看执行计划里有没有 Merge Join 被替换成 Hash Join，或者出现临时表（Temporary table）字样。如果有，说明数据库已放弃优化视图逻辑，建议把关键路径的 JOIN 提到外层，或改用物化视图/CTE。
权限与更新限制必须提前对齐
视图默认不可更新，除非满足三个硬条件：只映射单张基表、包含主键、没用聚合函数或 DISTINCT。但报表中间层几乎不可能满足——它必然 JOIN 多张表、含 COALESCE、有重命名。所以别指望 UPDATE dm_order_detail SET amount = 100 能成功，那只会报错。
更关键的是权限隔离：DBA 给分析师开 SELECT 权限时，通常只授视图，不授底层 base_* 表。一旦视图定义里用了未授权字段（比如 u.id_card），整个视图创建就会失败，且错误信息往往只报“permission denied”，不指明哪一列。
实操建议：
- 建视图前，用
SELECT语句先跑通底层逻辑，确认每列都有访问权 - 上线前，在测试环境用目标账号执行
SELECT * FROM 新视图 LIMIT 1，卡住就查缺哪张表的权限 - 别依赖视图做 DML，报表层只读；写操作走应用服务或专用 ETL 通道
中间层不是万能胶，它解决的是“逻辑复用”和“口径统一”，不是“性能加速”或“写入代理”。越早认清这点，越少半夜被报警叫醒。
