视图是统一口径最轻量、最可控的方式，需将维度逻辑固化进定义，强制字段名语义明确、时间函数确定、状态过滤前置，并通过UNION ALL归一化多源字段，仅固化稳定复用的维度逻辑，避免动态计算与频繁变更规则。
视图是统一口径最轻量、最可控的方式，前提是把维度逻辑固化进定义里，而不是留到查询时再拼。
为什么不能靠每次写SQL时手动对齐口径
不同业务线查“活跃用户”，有人用 DATE(event_time)，有人用 DATE(created_at)；算“新用户”时，营销侧按注册时间，销售侧却按首单时间——这些差异不会报错，但聚合结果一交叉就对不上。视图强制把字段名、时间截断逻辑、状态过滤条件全部锁死，后续所有引用都共享同一份解释。
- 字段名必须语义明确，比如统一叫
user_id、stat_date，不接受uid或dt这类缩写 - 时间处理必须用确定性函数：MySQL 用
DATE(event_time)，PostgreSQL 用(event_time::date)，避免NOW()或CURRENT_DATE这类运行时变量 - 状态过滤必须前置，比如只取
status IN ('completed', 'shipped')，而不是把脏数据放出去让下游自己筛
视图里怎么处理多业务线的字段不一致
当营销表有 source、销售表有 channel、客服表有 origin，硬 JOIN 容易字段错位。正确做法是在视图中做归一化映射，而不是在查询层适配。
- 用
UNION ALL合并各业务线数据，每个子查询都投射出相同字段名，如user_id、stat_date、event_type - 别用
UNION去重——它触发全局排序，大数据量下极慢；若不确定子查询是否已去重，宁可在外层包一层SELECT DISTINCT - 映射逻辑优先走
LEFT JOIN dim_channel，而非CASE WHEN source = 'wechat' THEN 'social'，避免新增渠道时漏改
哪些维度逻辑适合塞进视图，哪些不该
核心判断标准是：是否在三个以上报表或看板中重复出现，且规则稳定（半年内无变更预期）。
- 该塞的：时间维度拆解（
YEAR(stat_date)、QUARTER(stat_date)）、地区层级（province、city）、状态码转义（CASE WHEN status = 'S' THEN '已发货' END AS status_desc） - 不该塞的：动态财年偏移（如“财年从4月起”）、依赖实时参数的计算（如“最近7天环比”）、需频繁更新的业务规则（如优惠券类型权重）
- 必须加
COALESCE(region, '未知地区')类兜底，否则 NULL 在 BI 工具里分组行为不一致，Power BI 和 Tableau 处理方式完全不同
权限与依赖容易被忽略的关键点
视图不是“写完就能用”，它的执行权限继承自定义者，而底层表变更会直接导致视图失效——这点比临时表更隐蔽。
- 创建视图时用
CREATE VIEW v_user_daily AS ...，不要省略AS关键字，否则某些旧版 MySQL 会语法报错 - 如果视图依赖
orders和users，而有人删了users.id字段，视图仍存在，但首次查询时才报错：ERROR: columnu.iddoes not exist - 跨库引用必须显式写库名，如
sales_db.orders，否则迁移或同步时容易指向错误实例
真正难的不是写视图，而是确认哪些逻辑值得固化——一旦塞进去，改一次就得全链路回归测试。所以建议每建一个视图，都在注释里写清：适用场景、更新频率、下游依赖方。这不是形式主义，是防止半年后你自己都忘了当初为啥这么写。
