动态视图（VIEW）仅是无状态逻辑别名，不定义时间属性、watermark、主键或connector，不能替代动态表（TABLE）；真实流处理逻辑必须基于带时间属性和connector的TABLE实现。
动态视图（VIEW）本身不处理流式数据——它只是 SQL 层的逻辑别名，不带状态、不触发计算、不绑定时间属性。真正在流上起作用的是「动态表」（Dynamic Table），而 VIEW 只是对动态表的再封装，用错场景会直接导致结果错乱或作业卡死。
为什么CREATE VIEW不能替代CREATE TABLE
VIEW 不注册 connector、不定义 watermark、不声明时间属性，也不参与 changelog 编码。它只是把一段 SELECT 逻辑存起来，每次被引用时才展开执行。这意味着：
- 如果你在
VIEW里写了GROUP BY+ 窗口，但底层源表没定义WATERMARK，Flink 会默认按处理时间（PROCTIME）推算，结果不可重放、乱序严重 -
VIEW无法指定主键，下游做UPSERT或关联维表时会报Primary key is not defined - 对
VIEW执行INSERT INTO sink会失败，因为 Flink 不知道该用 Append 还是 Retract 模式输出
动态视图的正确使用位置：仅限逻辑复用层
它只适合做“无状态的、确定性转换”的抽象，比如字段重命名、常量补全、简单过滤。真实流处理逻辑必须落在 TABLE 上：
- ✅ 正确：先建带 watermark 和 connector 的源表
user_log，再用CREATE VIEW active_users AS SELECT user_id FROM user_log WHERE action = 'login' - ✅ 正确：在后续聚合中引用该视图，如
SELECT user_id, COUNT(*) FROM active_users GROUP BY user_id，但聚合必须写在 INSERT 语句里，且目标 sink 表需支持 retract - ❌ 错误：试图在
VIEW内部写TUMBLE(ts, INTERVAL '1' HOUR)并期望它自动触发窗口计算——窗口生命周期由底层表的时间属性决定，不是视图能控制的
Retract 输出必须显式落到支持更新的 Sink 表
即使你用 VIEW 包了一层聚合逻辑，最终输出仍取决于目标 TABLE 的定义方式。若下游是 print 或 kafka（未设 'format' = 'debezium-json'），Flink 默认走 Append 模式，UPDATE/DELETE 消息会被丢弃或转成重复行。
- 要让回撤生效，sink 表必须声明主键，并配置为 upsert 模式：
'connector' = 'jdbc'+'table.dialect' = 'mysql'+ 显式PRIMARY KEY (user_id) - Kafka sink 需配合 Debezium 格式：
'format' = 'debezium-json'，否则收到-U/+U消息也无法还原语义 - 用
print调试时，务必加SET 'execution.result-mode' = 'tableau'，否则控制台只显示+I行，看不到-U回撤动作
最常被忽略的一点：动态视图不改变底层表的 changelog 类型。如果源表是 append-only 流（如原始 Kafka 日志），那所有基于它的 VIEW 输出也必然是 append-only；想得到 retract 流，源头就必须是 upsert-capable 的（如 CDC 数据、带主键的数据库变更日志），这点无法靠 VIEW 弥补。
