应将JSON解析逻辑封装到视图中，避免业务SQL中重复使用JSON_EXTRACT：解决路径硬编码、类型处理缺失和重复解析性能问题；视图需统一做JSON_UNQUOTE和CAST类型转换，并可通过生成列+索引优化查询性能。
直接用 JSON_EXTRACT 写在业务 SQL 里，短期能跑通，长期会变成维护噩梦——字段路径硬编码、NULL 处理缺失、重复解析拖慢查询。真正可持续的做法，是把 JSON 解析逻辑收口到视图中。
为什么不能在业务查询里反复写 JSON_EXTRACT
每次业务 SQL 都手动写 JSON_EXTRACT(data, '$.user.profile.name') 这类表达式，会带来三个实际问题：
- 同一路径在多处出现时，某天 JSON 结构微调（比如
profile改成info），你得翻遍所有 SQL 改至少 5–10 个地方； -
JSON_EXTRACT返回的是带引号的 JSON 字符串（如"Alice"），不加JSON_UNQUOTE就直接比较或连接，会导致隐式类型转换失败或意外匹配； - MySQL 对同一列多次调用
JSON_EXTRACT不会自动复用解析结果，每次都是重新解析整段 JSON，CPU 开销随调用次数线性增长。
如何用视图封装 JSON_EXTRACT + JSON_UNQUOTE
核心是把“提取 → 去引号 → 类型转换”三步固化在视图定义里，对外暴露干净的列名。以 MySQL 为例：
CREATE VIEW event_parsed AS SELECT id, created_at, JSON_UNQUOTE(JSON_EXTRACT(payload, '$.user.id')) AS user_id, CAST(JSON_EXTRACT(payload, '$.metrics.duration') AS UNSIGNED) AS duration_ms, JSON_EXTRACT(payload, '$.tags') AS tags_json FROM raw_events;
这样业务方只需：
SELECT user_id, duration_ms FROM event_parsed WHERE duration_ms > 1000;
注意几点：
- 对数字字段，用
CAST(... AS UNSIGNED)或CAST(... AS DECIMAL(10,2))显式转类型，避免后续计算出错； - 对可能为 NULL 的路径（如
$.user.avatar_url），JSON_EXTRACT本身返回 NULL，无需额外判空，但别忘了JSON_UNQUOTE(NULL)还是 NULL； - 不要在视图里用
->或->>操作符替代函数——它们是语法糖，底层仍调用相同逻辑，且->>在 MySQL 5.7 中不支持嵌套数组访问（如$[0].name），而JSON_EXTRACT全版本兼容。
视图里处理数组和嵌套对象的常见陷阱
当 JSON 字段含数组（如 {"items": [{"id":1,"qty":2}, {"id":2,"qty":5}]}）时，不能靠单个 JSON_EXTRACT 展开成多行——视图本身不改变行数。此时必须配合 JSON_TABLE（MySQL 8.0+）或提前在 ETL 阶段展开。
如果坚持用视图，可行但受限的做法是：
- 用
JSON_EXTRACT(payload, '$.items[0].id')提取首项 ID，适合只关心“第一个”的场景； - 用
JSON_LENGTH(JSON_EXTRACT(payload, '$.items'))获取数组长度，用于条件过滤（如只查有多个 item 的记录）； - 把整个数组存为
tags_json这类 JSON 类型列，交由应用层解析，避免视图过度承担结构扁平化职责。
强行在视图里用 JSON_TABLE 会失去“简单封装”的初衷，且该函数返回的是派生表，无法直接作为视图列引用，必须嵌套子查询——这会让视图定义变得臃肿且难以调试。
性能与索引：视图本身不加速，但可引导优化
MySQL 视图是虚拟表，不存储数据，所以创建视图不会自动建索引。但你可以基于视图列建生成列（generated column）并索引：
ALTER TABLE raw_events ADD COLUMN user_id_g AS (JSON_UNQUOTE(JSON_EXTRACT(payload, '$.user.id'))) STORED, ADD INDEX idx_user_id_g (user_id_g);
这样既保持视图逻辑清晰，又让高频查询走索引。关键点：
- 必须用
STORED（非VIRTUAL），否则无法建索引； - 路径表达式要完全一致，包括大小写和空格，否则索引不生效；
- 如果 JSON 路径存在深层嵌套（如
$.data.response.body.items[0].name），生成列值为空或解析失败时会存 NULL，需在业务逻辑中容错。
最易被忽略的是：视图简化的是开发复杂度，不是查询性能。真正影响速度的，永远是底层 JSON 字段是否被有效索引、路径是否稳定、以及是否把高开销操作（如多层嵌套遍历）推到了应用层。
