SQL视图适合作为ODS层清洗入口，因其不存数据、只存逻辑，可延迟执行单行清洗、字段映射和基础过滤，保障原始数据保真、可追溯、低延迟；但不可替代ETL中间表，因不支持状态记录、不可写、无法聚合或去重。
SQL视图不能当ETL中间表用，但它是清洗逻辑最轻量、最可控的“接口层”——关键在于只封装单行计算、字段映射和基础过滤，别让它干聚合、去重或跨表关联的活。
为什么视图适合做ODS层清洗入口，但不适合替代中间表
视图不存数据，只存查询逻辑，所以它天然适合作为ODS层的“清洗契约”：原始数据不动，查的时候才按规则投射。这带来三个实际好处——源表加字段不影响下游（只要视图显式定义字段）、字段命名/类型不一致能统一遮盖、权限受限时DBA只需开放视图而非基表。但它无法解决ETL中必须固化状态的环节，比如增量抽取需要记录last_update_time，而视图里不能用变量；又比如去重后要写回目标库，视图本身不可写。
常见错误现象：SELECT * FROM ods_user_log 报错 column reference "id" is ambiguous，本质是多个源表都有id字段，但视图定义里没用AS重命名——这不是语法问题，是接口契约断裂。
- 必须显式写出所有字段，禁用
SELECT * - 日期分区字段（如
dt）保留在SELECT列表且不重命名，否则下游分区裁剪失效 - 涉及多源
id、name等通用字段，一律用AS指定标准别名，例如user_id AS user_key
哪些清洗操作可以放心塞进视图，哪些必须移出去
视图只该承担无状态、单行、低开销的转换。这类操作能被大多数引擎（Hive/Spark SQL/PostgreSQL）下推执行，不影响性能。一旦涉及跨行依赖或数据粒度变化，就必须拆到物化层。
可放进去的：TRIM()、UPPER()、COALESCE(col, 'unknown')、CAST(event_time AS TIMESTAMP)、REGEXP_REPLACE(col, '[\r\n\t]+', ' ')、基础WHERE dt = '${bdp.system.bizdate}'（配合调度变量）
必须移出去的：ROW_NUMBER() OVER (PARTITION BY ...)（窗口函数结果不能在视图WHERE中直接过滤）、GROUP BY聚合后再JOIN、去重后写回、跨库关联（MySQL视图查不了PostgreSQL表）
- Hive严格模式下用
COALESCE而非IFNULL - 字符串清洗建议组合使用：
TRIM(LOWER(REGEXP_REPLACE(col, '[\r\n\t]+', ' '))) - 避免在视图里写
WHERE status = 'active'——业务状态过滤应下推到调用方，否则视图失去通用性
PostgreSQL vs MySQL：视图执行行为差异直接影响ETL调度
PostgreSQL视图是“重写式”，每次调用都内联展开底层查询；MySQL 8.0+ 默认也是，但若视图含子查询或窗口函数，可能触发临时表，拖慢ETL任务。这意味着你得盯紧执行计划。
常见卡点：EXPLAIN SELECT * FROM sales_view 出现Materialize或Derived步骤，说明优化器已退化；PostgreSQL中带LATERAL或递归CTE的视图会让Airflow反复解析；MySQL中视图嵌套超3层（A→B→C→D），SHOW CREATE VIEW就能看到嵌套深度失控。
- 别在视图里引用另一个视图，尤其跨库或跨环境时
- ETL中需传参（如
last_date）必须靠外部调度器注入，视图自身不支持变量 - MySQL中若视图含
ORDER BY，多数版本不支持（SQL Server除外，且需配TOP）
真正容易被忽略的点是：视图字段名就是数据契约。下游Python脚本或dbt模型认的就是这些名字，改一个AS别名，整条链路就断。它不像物理表能随时ALTER COLUMN，一旦发布，就得当API一样维护。
