视图不能直接聚合非结构化数据，需先用JSON函数解析再投影；应避免在视图中GROUP BY，聚合留待上层查询；性能优化需依赖计算列索引或物化视图。
视图本身不能直接聚合非结构化数据
SQL视图只是封装 SELECT 查询的逻辑对象，它不改变数据物理形态。如果你的日志原始存为 TEXT、VARCHAR(MAX) 或 JSON 字符串（比如 log_content 字段里是 {"user":"a","action":"login","ts":"2026-11-01T08:30"}），那视图无法自动“解析”——必须先用数据库内置函数做结构化解析，再聚合。
常见错误是直接在视图里写 SELECT COUNT(*) FROM logs WHERE log_content LIKE '%error%'，这既低效又漏信息：没提取字段、无法索引、不能复用时间范围或用户维度。
- PostgreSQL 要用
jsonb_extract_path_text()或regexp_matches() - SQL Server 需依赖
JSON_VALUE()（2016+）或STRING_SPLIT()+CHARINDEX()组合 - MySQL 5.7+ 支持
JSON_EXTRACT()，但对嵌套日志需多层调用
审计日志场景下推荐的视图建法：先解析再投影
以你知识库中 audit_subscibers 表为例，虽然它已是结构化表，但真实日志往往更混乱。假设你有一张 raw_logs，其中 payload 是 JSON 字符串：
CREATE VIEW v_user_actions AS SELECT JSON_VALUE(payload, '$.user') AS user_name, JSON_VALUE(payload, '$.action') AS action_type, CAST(JSON_VALUE(payload, '$.ts') AS DATETIME2) AS event_time, JSON_VALUE(payload, '$.ip') AS client_ip FROM raw_logs WHERE ISJSON(payload) = 1 AND JSON_VALUE(payload, '$.user') IS NOT NULL;
关键点：
-
ISJSON()过滤掉损坏日志，避免JSON_VALUE()报错中断查询 - 显式
CAST(... AS DATETIME2)确保时间能用于GROUP BY或窗口函数 - 视图里不做
COUNT或AVG—— 聚合留给上层查询，保持视图的原子性和可组合性
聚合时别在视图里写 GROUP BY
有人会写 CREATE VIEW v_daily_error_count AS SELECT COUNT(*) c, CAST(ts AS DATE) d FROM logs WHERE payload LIKE '%ERROR%' GROUP BY CAST(ts AS DATE)。这看似省事，实则埋雷：
- 无法再按
user_name或client_ip二次分组 - 一旦需求变成“每小时错误率”，就得重建视图
- SQL Server 中，含
GROUP BY的视图默认不可更新，且可能绕过底层索引
正确做法是让视图只做“清洗+投影”，聚合交给业务查询：
SELECT user_name, COUNT(*) AS total_actions, COUNT(CASE WHEN action_type = 'Deleted a subscriber' THEN 1 END) AS deletes FROM v_user_actions WHERE event_time >= '2026-11-01' GROUP BY user_name;
性能陷阱：JSON 解析在 WHERE 条件中会全表扫描
如果写 WHERE JSON_VALUE(payload, '$.action') = 'login'，大多数数据库（包括 SQL Server 和 MySQL）无法利用 payload 字段上的索引——因为 JSON_VALUE() 是计算列，不是存储列。
解决路径只有两条：
- 加计算列并持久化索引：
ALTER TABLE raw_logs ADD action_gen AS JSON_VALUE(payload, '$.action') PERSISTED，然后在action_gen上建索引 - 用物化视图（SQL Server 叫“索引视图”）：要求视图确定性、无
GETDATE()等函数，并用WITH SCHEMABINDING创建，再在结果列上建唯一聚集索引
后者成本高但适合高频聚合；前者更轻量，适合中小规模日志表。别指望纯视图解决性能问题——它只是语法糖，不是执行引擎。
