SQL Server需启用Server Audit和Database Audit Specification来审计视图SELECT操作，仅捕获显式查询；PostgreSQL用pg_stat_statements按SQL文本反向匹配；MySQL通过Performance Schema的DIGEST_TEXT模糊查询；系统视图不记录访问行为。
SQL Server 中如何开启视图访问的审计日志
SQL Server 默认不记录谁、何时、访问了哪个视图，必须手动启用审核机制。核心是利用 SQL Server Audit 功能，配合 AUDIT_CHANGE_GROUP 和 SELECT 事件捕获——但注意：它只审计显式 SELECT 语句，不捕获视图被其他存储过程或函数内部调用的情况。
- 先创建服务器审核对象，输出到文件或 Windows 日志：
CREATE SERVER AUDIT ViewAccessAudit TO FILE (FILEPATH = 'C:\SQLAudit\');
- 再创建数据库级审核规范，明确监听
SELECT操作并限定目标视图：CREATE DATABASE AUDIT SPECIFICATION ViewSelectSpec FOR SERVER AUDIT ViewAccessAudit ADD (SELECT ON OBJECT::[dbo].[MyView] BY public);
- 启用时顺序不能错：先
ALTER SERVER AUDIT ViewAccessAudit STATE = ON，再ALTER DATABASE AUDIT SPECIFICATION ViewSelectSpec STATE = ON - 常见坑：
OBJECT::[schema].[view]必须拼写完全正确，大小写敏感（取决于数据库排序规则）；如果视图在sys或INFORMATION_SCHEMA下，审计不生效——这些是系统视图，无法直接审计
PostgreSQL 中用 pg_stat_statements 统计视图查询频次
pg_stat_statements 是最轻量、最实用的方式，但它统计的是「执行过的 SQL 文本」，不是逻辑对象。视图一旦被引用，其定义语句会被展开，原始 SELECT * FROM my_view 在统计中会消失，变成底层表的 JOIN 查询。
- 确保插件已启用：
shared_preload_libraries = 'pg_stat_statements'在postgresql.conf中，并重启 - 创建扩展：
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
- 查访问频率时，得反向匹配 SQL 文本：
SELECT query, calls, total_time FROM pg_stat_statements WHERE query ILIKE '%my_view%' ORDER BY calls DESC LIMIT 10;
- 注意：
calls是执行次数，不是“视图被访问次数”——如果一条 SQL 同时查了 3 个视图，calls只加 1；且默认只保留 1000 条语句，高频环境需调大pg_stat_statements.max
MySQL 8.0+ 使用 Performance Schema 追踪视图访问
MySQL 不支持直接审计视图对象，但可通过 performance_schema.events_statements_summary_by_digest 表，结合 digest_text 匹配视图名。前提是开启相关消费者和仪器：
- 确认已启用：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_statements_digest';
- 检查是否采集足够长的 SQL 文本：
performance_schema_max_sql_text_length默认 1024 字节，若视图名靠后可能被截断，建议设为 4096 - 查询示例（注意转义下划线，MySQL LIKE 中
_是通配符）：SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%SELECT%`my\_view`%' ORDER BY COUNT_STAR DESC;
- 限制明显：无法区分视图是直接查询还是嵌套在存储过程中；且
DIGEST_TEXT已参数化（WHERE id = ?），若视图名出现在字面量位置（如SELECT 'my_view' AS source），就完全匹配不到
为什么不能依赖 INFORMATION_SCHEMA.VIEWS 或 pg_views 查访问频次
这两个系统视图只描述「视图存在」和「定义」，不包含运行时行为数据。有人误以为刷新一次 pg_views 就能知道最近谁用了它——其实它连最后修改时间都不存，更别说访问计数。
-
INFORMATION_SCHEMA.VIEWS的CHECK_OPTION、IS_UPDATABLE等字段全是静态元数据，跟使用无关 -
pg_views的definition字段是建视图时的原始 SQL，哪怕你删了视图，只要没清理 catalog，它还留着 - 真正要监控访问，必须走运行时采集路径：SQL Server 审计、PostgreSQL 的
pg_stat_statements、MySQL 的 Performance Schema——没有捷径，也没有跨版本通用方案
真实场景里，最容易被忽略的是权限粒度与审计覆盖范围的错位：比如给用户授予了 VIEW DEFINITION 权限，他能看到视图结构，但这不会触发任何审计事件；只有实际执行 SELECT 才算“访问”。而很多 DBA 一开始只盯着“谁有权限”，结果监控漏了一半。
