SQL Server需显式启用Server Audit和Database Audit Specification才能审计视图SELECT操作，仅捕获显式查询；PostgreSQL用pg_stat_statements通过ILIKE模糊匹配SQL文本中的视图名；MySQL则依赖Performance Schema的DIGEST_TEXT字段进行类似模糊识别。

SQL Server 必须显式启用审计，且只捕获直接 SELECT

SQL Server 默认完全不记录视图访问行为。你执行 SELECT * FROM MyView，只要没开审计，日志里就什么都没有。核心限制是：它只审计「显式调用」，不审计视图被存储过程、函数或另一个视图内部引用的情况。

必须按顺序操作，漏一步就无效：

• 先创建服务器级审计对象：CREATE SERVER AUDIT ViewAccessAudit TO FILE (FILEPATH = 'C:\SQLAudit\');
• 再建数据库级规范，目标必须写全：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::[dbo].[MyView] 写成 OBJECT::MyView 或大小写不一致（尤其在区分大小写的排序规则下）；对 sys 或 INFORMATION_SCHEMA 下的系统视图审计会静默失败。

PostgreSQL 用 pg_stat_statements 反向匹配，不是“查视图”而是“查含视图名的 SQL”

pg_stat_statements 不跟踪对象，只统计执行过的完整 SQL 文本。视图一旦被引用，查询会被重写为底层表的 JOIN，原始视图名在 query 字段中可能只作为字符串片段存在。

所以不能指望“统计 MyView 被查了多少次”，只能靠模糊匹配：

• 确保插件已加载：shared_preload_libraries = 'pg_stat_statements' 在 postgresql.conf 中，且已重启
• 创建扩展：CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
• 查最近高频含视图名的语句：SELECT query, calls FROM pg_stat_statements WHERE query ILIKE '%my_view%' ORDER BY calls DESC LIMIT 5;

注意：calls 是该 SQL 文本执行次数，不是视图被访问次数；一条语句查了 3 个视图，calls 也只加 1；默认最多保留 1000 条，高并发环境需调大 pg_stat_statements.max。

MySQL 8.0+ 靠 Performance Schema 的 DIGEST_TEXT 模糊识别

MySQL 没有视图对象级审计能力，但 performance_schema.events_statements_summary_by_digest 表会归一化 SQL 文本（如把 WHERE id = 123 变成 WHERE id = ?），同时保留原始 DIGEST_TEXT 字段中的视图名。

关键点在于匹配逻辑和索引利用：

• 开启 Performance Schema（默认通常已开），确认 events_statements_history_long 或摘要表启用
• 查询示例：SELECT DIGEST_TEXT, COUNT_STAR FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE '%`my_view`%' OR DIGEST_TEXT LIKE '%my_view%';
• 不要只依赖 DIGEST_TEXT 匹配——它可能被截断或归一化掉视图名，建议配合 events_statements_history_long 做实时抓取补漏

性能隐患：全表扫描 events_statements_summary_by_digest 很慢，高频环境需定期清理或限制查询范围（如加 WHERE LAST_SEEN > DATE_SUB(NOW(), INTERVAL 1 HOUR)）。

所有方案都绕不开一个事实：视图不是数据实体，审计永远是间接的

你真正想监控的“谁在什么时候查了哪个视图”，数据库底层并不天然支持这个语义。SQL Server 审计的是语法事件，PostgreSQL 和 MySQL 统计的是执行文本——它们都发生在查询重写之后、优化器展开之前那个短暂窗口。

这意味着：跨库迁移时别指望同一套脚本能复用；应用层做了 SQL 拼接（比如 "SELECT * FROM " + viewName），匹配会失效；而最隐蔽的坑是——视图嵌套三层后，原始视图名可能彻底从最终执行计划里消失，连模糊匹配都找不到。