MySQL 8.0+中JSON_EXTRACT视图无法自动下推过滤，必须用确定性路径（如'$.user.id'）+显式类型转换（如CAST(... AS UNSIGNED)）+STORED虚拟列支撑，否则每次查询均全量解析JSON。
MySQL 8.0+ 中用 JSON_EXTRACT 创建可下推过滤的虚拟视图
直接在 CREATE VIEW 里套 JSON_EXTRACT 不等于高性能——MySQL 只有在视图定义中使用「确定性函数 + 简单路径表达式」且查询时能匹配上索引前缀时，才能把 WHERE 条件下推到基表扫描阶段。否则就是每次查视图都全量解析 JSON 字段，IO 和 CPU 开销翻倍。
实操建议：
- 路径必须写死、不可拼接：
JSON_EXTRACT(data, '$.user.id')✅；JSON_EXTRACT(data, CONCAT('$.', 'user.id'))❌（非确定性，无法下推） - 字段类型要显式转换，避免隐式转换阻断优化：
CAST(JSON_EXTRACT(data, '$.status') AS UNSIGNED)，而不是裸用JSON_EXTRACT - 视图列名别用保留字或带点号，比如别叫
user.id，改用user_id，否则后续SELECT * FROM v WHERE user.id = 123会语法报错 - 如果基表已有
data字段上的GENERATED COLUMN（如user_id INT AS (JSON_EXTRACT(data, '$.user.id')) STORED），优先基于该列建视图，性能更稳
PostgreSQL 中用 jsonb_path_query 或 ->> 定义视图时的索引适配要点
PostgreSQL 对 JSONB 视图的优化逻辑和 MySQL 不同：它不依赖“下推”，而依赖「表达式索引」是否覆盖视图中的提取逻辑。只要你在基表上为视图里实际用到的路径建了表达式索引，查询就能走索引。
常见错误现象：EXPLAIN 显示 Seq Scan，但明明写了 WHERE info->>'status' = 'active' —— 很可能是因为没在 info 列上建对应表达式的索引。
实操建议：
- 视图中用
info->>'user_id'，就在基表执行：CREATE INDEX idx_users_info_user_id ON users ((info->>'user_id'));
- 避免在视图里用
jsonb_path_query做多层遍历（如jsonb_path_query(info, '$.orders[*] ? (@.amount > 100)')），这种无法被索引加速，且每次调用开销大 - 如果视图需兼容空值或结构变异（例如
$.tags有时是字符串、有时是数组），务必用COALESCE((info->>'tags')::text, '')统一类型，否则排序/比较可能意外失败
SQL Server 2016+ 的 OPENJSON 视图为什么总变慢？关键在 WITH 子句写法
SQL Server 的 OPENJSON 本身不支持在视图中直接参数化路径，所以你写的 OPENJSON(data) WITH (id INT '$.id') 是静态的，但性能陷阱藏在 WITH 的类型声明里：一旦声明为 INT 而实际 JSON 中是字符串 "123"，SQL Server 会在运行时做隐式转换并放弃部分优化路径。
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
使用场景：适合结构相对固定的配置类 JSON（如用户 profile），不适合日志级动态 schema 数据。
实操建议：
-
WITH中所有字段类型必须和 JSON 实际值类型严格一致：数字用INT/DECIMAL(10,2)，字符串统一用NVARCHAR(100)，布尔用BIT - 不要省略
AS JSON子句来嵌套解析，例如permissions NVARCHAR(MAX) AS JSON，否则外层再用OPENJSON嵌套就会触发多次解析 - 如果基表有百万级以上数据，视图里尽量只
SELECT必需字段，避免SELECT *拉出全部OPENJSON展开列——每多一列，就多一次 JSON 解析开销
跨数据库通用提醒：虚拟视图 ≠ 物理投影，JSON 解析成本始终存在
无论哪种数据库，只要视图定义里含 JSON 解析逻辑，就代表每次查询该视图时，符合条件的每一行都会执行一次解析。没有银弹能绕过这个本质开销。
最容易被忽略的地方是：开发时用千行测试数据看不出问题，上线后面对 500 万行 + 高并发聚合查询，CPU 突然飙高，而 EXPLAIN 里又看不到明显瓶颈——其实就卡在 JSON 字段反复解析上。
真要高性能，得提前把关键字段冗余成普通列，或者用物化方式（如 PostgreSQL 的物化视图 + 定时刷新、MySQL 的生成列 + 索引）。虚拟视图只是权宜之计，不是替代方案。
