创建数据库视图的开销是多少？大表修改期间用视图合并两表是否可行

视图创建开销问题 #

你提到的这种标准SQL视图（非物化视图）本质只是一段预存储的查询逻辑，创建过程仅会在数据库中写入视图的元数据定义，不会扫描、处理两张表的任何实际数据，创建开销极低，耗时一般在毫秒级，和你修改大表需要数周的开销完全不在一个量级，完全不用担心性能问题。

视图 vs 直接写UNION ALL的选择 #

两者最终执行的查询逻辑完全一致，核心差异在维护成本和可控性上，你可以根据自己的业务场景选择：

• 优先推荐用视图的场景：
  • 涉及读取该表的业务代码位置很多，逐个修改UNION ALL容易出现遗漏、写错的问题
  • 后续合并数据后需要快速切回原表单表查询，只用修改视图定义即可，业务侧无需发版调整
• 更适合直接写UNION ALL的场景：
  • 读取该表的查询逻辑很少，只有少数几个入口，修改成本很低
  • 你发现当前数据库的优化器无法将查询的WHERE条件正确下推到两张子表，导致视图查询会先全量合并两张表数据再过滤，性能损耗极大，这种情况直接在业务查询里给两个子句都加上对应过滤条件，性能更可控。

注意事项 #

你当前写的视图用了SELECT *，非常不推荐：
两张表的字段顺序、字段类型如果出现不一致，会直接导致视图返回结果错乱，建议显式列出所有需要的字段，示例如下：

CREATE VIEW MY_TABLE_VIEW AS
   SELECT id, col1, col2, create_time FROM MY_TABLE
   UNION ALL
   SELECT id, col1, col2, create_time FROM MY_TABLE_COPY

另外需要确认两张表没有主键/唯一键重复的数据，你当前场景原表仅读、新表仅接新写入，没有数据重叠，用UNION ALL是最优选择，不要换成带去重逻辑的UNION，会额外增加很多性能开销。

内容的提问来源于stack exchange，提问作者bbpi