视图不能做数据归档，仅封装查询语句；CREATE VIEW 不存储数据，执行时动态运行其定义的 SELECT（如从 orders 表按 created_at 过滤）。
视图本身不能做数据归档，它只是查询的封装
SQL 视图（CREATE VIEW）不存储数据，只保存 SELECT 语句。你执行 SELECT * FROM archived_orders，实际跑的是背后定义的查询——比如从 orders 表里 WHERE created_at 。它不移动、不复制、不删除任何行，所以别指望靠视图自动“归档”。
常见错误现象：INSERT INTO archived_orders ... 报错 “view is not updatable” 或直接拒绝写入；有人误以为建个视图就等于有了历史表，结果上线后发现查询越来越慢，因为每次都在全量扫描原表。
- 视图适合读多写少、逻辑固定、权限隔离的场景（比如给 BI 工具暴露一个“已关闭订单快照”）
- 如果真要物理归档（腾出主表空间、提升 OLTP 性能），必须用
INSERT INTO history_orders SELECT ... FROM orders WHERE ...+DELETE组合 - MySQL 8.0+ 和 PostgreSQL 支持物化视图插件（如
pg_cron+ 定时刷新），但原生 SQL 标准不支持，别默认以为有
用视图模拟归档查询时，WHERE 条件必须可下推
想让视图查得快，关键不是视图本身，而是数据库能否把过滤条件（比如时间范围）下推到基表扫描层。否则视图一展开，可能全表扫 orders 再过滤，历史数据越多越卡。
使用场景：你想查“所有 2022 年前的订单”，但不想每次写冗长 WHERE；建视图省事，但性能取决于索引和谓词写法。
- 确保基表上有对应字段的索引，例如
CREATE INDEX idx_orders_created ON orders(created_at) - 避免在视图定义里对归档字段做函数操作，比如
YEAR(created_at) 会失效索引；改用 <code>created_at - PostgreSQL 中可用
EXPLAIN看视图执行计划是否命中索引；MySQL 用EXPLAIN FORMAT=TREE更直观
归档逻辑变化时，视图比真实表更难维护
业务说“2022 年订单不算归档，得从 2021 年底开始”，这时候改视图是快，但所有依赖它的应用、报表、ETL 脚本都会悄无声息地拿到新结果——没有版本控制，没有迁移确认点。
对比真实归档表：history_orders_2021 和 history_orders_2022 是独立对象，改逻辑只需新建表、重跑任务、切换下游源，风险可控。
- 视图无法加注释说明“此视图按 T+1 归档规则生成”，DDL 里没地方写业务语义
- Git 里存视图 DDL 没用：没人 review
ALTER VIEW的影响范围，而CREATE TABLE AS变更必然触发 CI 检查 - 如果视图跨库/跨 schema（比如从
prod.orders查，写入到archive.history），权限模型容易漏配，报permission denied for relation orders
真正需要归档动作时，视图只能当“查询入口”，不能当“执行主体”
归档本质是 ETL：抽取（SELECT）、转换（加归档标记、脱敏）、加载（INSERT INTO history）。视图顶多承担第一环节的“抽取逻辑封装”，后面两步必须显式写在脚本或作业中。
一个务实做法：用视图定义归档范围，再用它驱动真实归档任务。
CREATE VIEW pending_archive_orders AS SELECT id, customer_id, amount, created_at FROM orders WHERE created_at < '2023-01-01' AND status = 'closed';
然后在定时任务里跑：
INSERT INTO history_orders SELECT * FROM pending_archive_orders;DELETE FROM orders WHERE id IN (SELECT id FROM pending_archive_orders);- 注意：第二步 DELETE 前务必加事务和行数校验，防止误删；MySQL 需关掉
safe_updates或加主键条件
归档真正的复杂点不在语法，而在一致性边界——比如订单关联支付记录，是只归档订单，还是连带支付一起走？视图解决不了这种跨实体约束，得靠应用层或存储过程兜底。
