最务实确认视图是否被使用的方法是重命名观察：先验证可执行，再重命名加日期后缀，盯紧24–48小时日志与报错；若无报警，仍需查sys.sql_expression_dependencies递归检查隐式依赖，并覆盖完整业务周期。

不能只查缓存，更不能直接删——SQL Server 和 PostgreSQL 的执行计划缓存随时可能被清空或淘汰，查不到调用记录 ≠ 没人用。

查 sys.dm_exec_query_stats 但必须加时间过滤和 objectid 校验

SQL Server 中最常被误用的查询就是漏掉 qs.last_execution_time > DATEADD(day, -30, GETDATE()) 和 st.objectid IS NOT NULL。前者防止返回过期缓存（比如重启后残留的老记录），后者排除动态 SQL 和跨库引用导致的误判。

• st.text LIKE '%your_view_name%' 易误伤：视图名是 vw_user，而 SQL 里写了 WHERE user_id = ? 就会命中
• 必须在目标数据库上下文中执行，否则 DB_ID() 和 OBJECT_NAME(st.objectid, st.dbid) 会错位
• 查到的结果只是“近期出现在缓存里的调用”，不是“所有调用”；缓存淘汰、DBCC FREEPROCCACHE、内存压力都会让它为空

重命名 + 观察是唯一能确认“真没人用”的办法

缓存不可靠，日志难覆盖全量，代码扫描又容易漏——最务实的做法是制造一次可控中断，看有没有人报警。

• 先用 SELECT TOP 1 * FROM your_view 确认视图当前可执行且不报错
• 执行 EXEC sp_rename 'old_view', 'old_view_unused_20261013';（带日期后缀，方便回滚）
• 盯紧接下来 24–48 小时的应用日志、ETL 调度失败通知、报表平台报错（尤其是 Invalid object name）
• 如果期间有报警，立刻 sp_rename 回去，并标记该视图为“疑似关键”

别跳过依赖检查：存储过程/函数/其他视图可能隐式调用

即使缓存和重命名都没触发报警，仍可能漏掉静态依赖。视图被其他数据库对象引用时，不会出现在查询缓存里，但删除会导致那些对象编译失败。

• 查显式依赖：SELECT * FROM sys.sql_expression_dependencies WHERE referenced_id = OBJECT_ID('your_view')
• 特别注意 is_selected 和 is_updated 字段：值为 1 表示该视图被 SELECT 或 UPDATE 引用，不是“仅定义存在”
• 递归检查：若 A 视图引用 B，B 引用 C，而你只查了 A → B，就可能误删 C
• 系统视图如 sys.views 不记录调用历史，只存定义；别指望靠它判断活跃度

真正危险的不是查不到调用记录的视图，而是那些只在每月结算脚本里跑一次、或只在特定错误分支中触发的视图——它们几乎从不进缓存，也很难被代码扫描捕获。重命名观察窗口必须覆盖完整业务周期，比如财务类视图至少等一个结账日。**没报警不等于安全，只是还没撞上那个时间点。**