不能用ROLLBACK回滚视图，因为视图是DDL操作且隐式提交，本质是虚拟表；上线后变慢需先验证是否真由视图引起，再通过删视图、切回原SQL、补监控完成安全降级。
ROLLBACK 对视图无效——视图本身不存数据，上线后变慢不是“事务未提交”，而是查询逻辑或执行计划恶化。回滚视图不能靠 ROLLBACK，得删视图、切回原SQL、或快速切版本。
为什么不能用 ROLLBACK 回滚视图？
视图是虚拟表，本质是保存的 SELECT 语句定义。执行 CREATE VIEW 是 DDL 操作，在 MySQL/PostgreSQL 中会隐式提交，无法被 ROLLBACK 撤销；即使在支持事务 DDL 的 PostgreSQL 里，视图创建成功即生效，回滚事务也只影响 DML，不影响已建好的视图结构。
上线后慢查询，优先验证是否真由视图引起
别急着删视图——先确认慢的真是它，而不是巧合叠加了其他变更：
- 用
EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=TREE（MySQL 8.0+）对比视图查询和等价原始 SQL 的执行计划，看是否多了嵌套循环、丢失索引、或物化开销 - 检查视图定义里是否含
ORDER BY、LIMIT、DISTINCT或多层JOIN，这些在视图中固化后，外部再加条件可能无法下推，导致全量计算 - 确认应用是否误用了
SELECT * FROM view_name，而视图底层查了 10 张表，字段膨胀严重 - 查
pg_stat_views（PG）或information_schema.VIEWS+ 手动比对慢查询日志，排除是同一时段其他 SQL 或连接数飙升干扰
安全回滚三步：删视图 → 切回原逻辑 → 补监控
真正有效的“回滚”是让业务流量绕过视图，而非撤销 DDL：
- 先执行
DROP VIEW IF EXISTS view_name（MySQL/PG 都支持），注意确认无其他依赖该视图的存储过程、函数或报表工具直连——可先SELECT * FROM pg_depend（PG）或SELECT * FROM information_schema.ROUTINES WHERE ROUTINE_DEFINITION LIKE '%view_name%'（MySQL）扫描依赖 - 应用层同步切换：把原来
SELECT * FROM view_name WHERE ...改回等效的原始多表 JOIN SQL，并确保 WHERE 条件能命中索引（比如把视图里写的o.create_time >= NOW() - INTERVAL '30 days'拆成具体时间戳常量） - 上线后立刻验证：用相同参数压测，对比 QPS、P95 延迟、
EXPLAIN输出；同时在应用日志里加标记，记录“视图降级完成”，便于后续复盘
下次上线视图前必须卡住的检查点
视图不是语法糖，是执行路径锁死器。容易被忽略的硬伤：
- 视图定义里禁止写
SELECT *—— 字段顺序、类型、NULL 性都会固化，下游改表加字段后视图可能报错或漏数据 - 所有 JOIN 条件必须有索引支撑，且不能依赖“隐式转换”（如
user_id VARCHAR关联orders.user_id INT），否则视图一用就慢 - 上线前必须在生产镜像环境跑真实流量采样：用 pt-query-digest 抓 1 小时慢日志，过滤出调用该视图的 SQL，单独压测
- MySQL 用户尤其注意：
ALGORITHM = MERGE（默认）才能下推条件；若视图含子查询或聚合，会强制TEMPTABLE，性能断崖下跌——这种视图根本不该上线
视图上线后的“回滚”，本质是服务降级决策，不是数据库事务操作。最危险的错觉，就是以为删了视图就万事大吉——而没同步切走流量、没验证原始 SQL 是否还有效、也没留痕到底哪一行定义引发了执行计划劣化。
