SQL视图（VIEW）是数据库中非常常用的逻辑封装手段，它能简化查询、隐藏底层表结构。但随着业务迭代，大量视图会逐渐变成“僵尸对象”——创建时有用，之后几个月甚至几年没人碰过。这些无用视图不仅让对象管理变得混乱，还可能在表结构变更时引发意外的依赖报错。本文将围绕如何根据最后访问时间筛选并清理无用视图展开，给出完整的可执行方案。
一、为什么不能随便删视图：先搞清楚访问记录的原理
在SQL Server中，系统并没有一个直接叫做“视图最后访问时间”的字段，视图的访问信息需要借助动态管理视图（DMV）来间接获取。最核心的是sys.dm_db_index_usage_stats，它会记录被查询执行计划引用过的对象的使用统计，包括最后使用时间last_user_seek、last_user_scan、last_user_lookup等列。普通视图本身没有索引，但只要它被外层查询展开引用，底层相关对象就会被统计到。
更直接的方式是使用sys.dm_exec_query_stats配合sys.dm_exec_sql_text，从执行计划的缓存中解析出哪些SQL语句引用了哪些视图，以及这些语句最后一次执行的时间。这种方式精度更高，能精确到具体某个视图名被哪条SQL访问过。
必须强调一点：DMV的数据在SQL Server实例重启后会清零，执行计划缓存也可能因为内存压力被清理。所以如果你观察的时间窗口太短，得出的结论并不可靠。建议至少连续观察30天以上，覆盖月度报表、季度任务等低频访问场景，再决定哪些视图可以删除。
二、查询视图最后访问时间的完整脚本
下面这段脚本综合了计划缓存和索引使用统计两个维度，列出当前数据库中所有视图以及它们的最后引用时间：
-- 查询当前库中所有视图的最后访问情况
SELECT
v.name AS view_name,
v.create_date,
v.modify_date,
MAX(qs.last_execution_time) AS last_access_time,
COUNT(qs.plan_handle) AS exec_count
FROM sys.views v
LEFT JOIN sys.dm_exec_query_stats qs
ON qs.sql_handle IN (
SELECT sql_handle
FROM sys.dm_exec_query_stats
)
OUTER APPLY sys.dm_exec_sql_text(qs.plan_handle) st
WHERE v.object_id NOT IN (
-- 排除掉在计划缓存中能找到引用记录的视图
SELECT DISTINCT o.object_id
FROM sys.dm_exec_query_stats qs2
CROSS APPLY sys.dm_exec_sql_text(qs2.sql_handle) st2
CROSS APPLY sys.dm_exec_query_plan(qs2.plan_handle) qp
JOIN sys.views o ON st2.text LIKE '%' + o.name + '%'
)
GROUP BY v.name, v.create_date, v.modify_date
ORDER BY last_access_time DESC;
上面这个写法在视图数量很多时性能会下降，因为对计划文本做LIKE匹配开销不小。更实用的做法是简化为两步：先导出所有视图名清单，再用一段脚本从计划缓存中提取每个视图名的最后匹配时间：
-- 简化版：逐个视图名在计划缓存中查找最后出现时间
DECLARE @view_name sysname, @last_time datetime;
DECLARE cur CURSOR FOR
SELECT name FROM sys.views;
OPEN cur;
FETCH NEXT FROM cur INTO @view_name;
WHILE @@FETCH_STATUS = 0
BEGIN
SELECT @last_time = MAX(qs.last_execution_time)
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE st.text LIKE '%' + @view_name + '%';
PRINT @view_name + ' => ' + ISNULL(CONVERT(varchar(30), @last_time, 120), '无访问记录');
FETCH NEXT FROM cur INTO @view_name;
END
CLOSE cur;
DEALLOCATE cur;
运行后你会得到一份清单，显示“无访问记录”的视图就是重点怀疑对象。当然要注意LIKE匹配的误判问题：如果视图名是常见的单词（比如vw_User可能匹配到包含User的其他语句），建议给视图名加上更严格的匹配模式，例如'%' + @view_name + '%'改为匹配'dbo.' + @view_name这种带架构前缀的形式，能显著减少误报。
三、删除前的依赖检查与安全批量清理
确认视图长期无人访问只是第一步，删除前还必须做依赖检查。一个视图可能被存储过程、函数甚至另一个视图引用，直接删除会导致上层对象运行时报错。SQL Server提供了sys.dm_sql_referencing_entities函数来查询谁引用了指定视图：
-- 检查视图被哪些对象引用
SELECT
referencing_schema_name,
referencing_entity_name,
referencing_id,
referencing_class_desc
FROM sys.dm_sql_referencing_entities('dbo.vw_OrderSummary', 'OBJECT');
如果返回结果为空，说明当前库内没有对象依赖它。但还要考虑跨数据库引用和应用程序代码直接调用的情况，这两者系统视图查不到。稳妥的做法是：先把候选视图重命名而不是直接删除，例如把vw_OrderSummary改名为zz_deprecated_vw_OrderSummary，观察一到两周，如果没有任何报错或业务反馈，再执行真正的删除。这是数据库清理工作中的经典“软删除”策略，成本极低但能规避绝大多数风险。
最终批量删除时，建议先生成删除脚本留档，而不是直接在循环里执行DROP VIEW：
-- 为长期未访问且无依赖的视图生成删除脚本（先留档再执行）
SELECT 'DROP VIEW ' + QUOTENAME(s.name) + '.' + QUOTENAME(v.name) + ';'
FROM sys.views v
JOIN sys.schemas s ON v.schema_id = s.schema_id
WHERE v.create_date < DATEADD(MONTH, -6, GETDATE())
AND NOT EXISTS (
SELECT 1 FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE st.text LIKE '%' + v.name + '%'
AND qs.last_execution_time > DATEADD(MONTH, -2, GETDATE())
);
注意这里用了QUOTENAME来处理可能包含特殊字符的对象名，并把“近两个月有访问记录”作为排除条件，比单纯看计划缓存是否存在更严谨。生成的脚本保存到文件中，人工复核一遍再执行，比全自动删除可控得多。
四、清理后的收尾工作与长期机制
删除视图后别忘了更新统计信息和整理文档。虽然删除视图本身不影响表数据，但如果清理的同时也移除了相关的索引视图，建议对涉及的表执行一次DBCC UPDATEUSAGE或重建索引，确保系统统计准确。对象文档和数据字典也要同步更新，避免后来者按照旧文档去查询一个已经不存在的视图。
更值得做的是建立长期机制，而不是每次都临时排查。可以创建一张日志表，配合SQL Server Agent定时作业，每周把计划缓存中各视图的最后访问时间快照写入日志表。这样积累几个月的数据后，你就拥有了一份真实可靠的访问历史，清理决策不再依赖单一时点的缓存快照。类似的思路也适用于MySQL等数据库，只是具体手段不同——MySQL可以通过开启general_log或performance_schema中的performance_schema.events_statements_summary_by_digest来统计语句级的视图引用情况。
总结一下核心流程：先通过DMV收集访问时间，观察足够长的周期，然后做依赖检查，采用重命名过渡的软删除策略，最后留档执行DROP VIEW。按照这个流程操作，即使是生产库也能安全地完成视图瘦身，让数据库对象清单重新变得清爽清晰。