最稳妥的做法是修改视图定义为显式报错或返回提示信息，而非硬删；需结合查询日志、审计函数和缓冲期综合判断调用方并安全下线。
怎么给 SQL 视图打“已废弃”标记
数据库里没标准的 DEPRECATED 属性，硬删会炸掉依赖它的应用。最稳妥的做法是改视图定义，用显式报错代替逻辑——让调用者一查就看到提示，而不是静默返回错误数据。
- PostgreSQL / SQL Server：在视图定义里加
RAISE EXCEPTION 'view_xxx is deprecated since 2024-06'（PG）或THROW 50000, 'view_yyy is deprecated', 1（SQL Server） - MySQL：不支持视图内抛异常，改用
SELECT 'ERROR: view_zzz is deprecated' AS message, NULL AS real_column占位，靠应用层识别字符串 - 别用注释（
-- deprecated）或命名（old_user_view_v1），这些对运行时零约束力
如何快速发现谁还在调用这个视图
依赖关系不是静态的，pg_depend 或 sys.sql_expression_dependencies 只能抓到显式引用，漏掉拼接 SQL、ORM 动态查询、报表工具里的硬编码表名。
- 开启查询日志（如 PostgreSQL 的
log_statement = 'all'+log_min_duration_statement = 0），跑一周后用grep 'view_name' pg_log/*.log扫描真实调用 - 在视图里加埋点：比如 PostgreSQL 中用
pg_stat_activity查当前 client_addr + application_name，再写入审计表 - 注意：BI 工具常缓存元数据，即使你改了视图，前端可能还显示旧字段名，得手动刷新连接或清缓存
ALTER VIEW 会中断正在执行的查询吗
会，但只影响新发起的查询。已运行中的查询不受影响——因为 PostgreSQL/SQL Server 都基于事务快照读取视图定义，但 ALTER VIEW 是 DDL，会拿 ACCESS EXCLUSIVE 锁，后续所有 SELECT 都得排队等它完成。
- 高并发场景下，这个锁可能卡住秒级甚至更久，尤其当视图依赖大表或复杂 CTE 时
- 安全做法是选低峰期执行，或先用
SELECT pg_backend_pid(), state, query FROM pg_stat_activity WHERE query LIKE '%view_name%'确认没长查询挂着 - MySQL 的
CREATE OR REPLACE VIEW同样会锁，且不支持事务回滚，出错就得手动恢复
监控废弃视图被调用的最小可行方案
不用上整套 APM，一个触发器+一张小表就够。关键是把“谁、什么时候、从哪来”记下来，而不是只记次数。
- 在视图包装一层函数（如
deprecated_vw_users()），函数里先插入审计记录，再RETURN QUERY SELECT * FROM real_vw_users - 审计表至少含：
called_at timestamp,client_ip inet,app_name text,backend_pid int - 别依赖
current_user——很多应用用统一数据库账号，真正区分调用方得看application_name或连接字符串里的program_name
实际操作中，最难的是确认“没人用了”。日志可能漏掉离线任务、夜间脚本、或者压根没连监控的测试环境。留个缓冲期比强行下线重要得多。
