直接查JSON字段慢因解析耗CPU而非I/O等待，AWR中“Top Events”不显异常，需查“DB CPU”占比及“SQL ordered by CPU Time”，重点关注JSON_VALUE等函数使用、执行计划中JSON EVALUATION STEP、函数索引命中情况及ASH中ON CPU会话。
为什么直接查JSON字段容易慢，但AWR里看不出明显异常
因为json解析本身不产生传统等待事件（比如 db file sequential read），awr的“top events”页常显示负载平稳，但实际执行耗时高。真正瓶颈藏在cpu和解析开销里——awr默认不突出展示这部分，除非你主动看“db cpu”占比和“sql ordered by cpu time”。
常见现象是：某条含 JSON_VALUE 或 JSON_EXISTS 的SQL在应用端响应超2秒，但AWR报告里它排不进Top 10 SQL；或者它执行次数少、单次耗时高，被平均值稀释掉了。
- 必须手动检查“SQL ordered by CPU Time”，而非只看“Elapsed Time”或“Executions”
- 重点关注
JSON_VALUE、JSON_EXISTS、JSON_TABLE出现在WHERE或SELECT中的SQL - 如果该SQL的“CPU Time per Execution”远高于其他SQL（比如 >500ms），基本可判定JSON解析是主因
怎么从AWR里快速定位JSON查询的执行计划缺陷
AWR报告本身不直接展示执行计划，但“SQL Statistics”页每条SQL旁都有一个“Plan Hash Value”。你需要拿着这个值去查 v$sql_plan 或用 DBMS_XPLAN.DISPLAY_AWR 提取真实计划。
关键要看三处：
- 是否出现
JSON EVALUATION STEP操作符——这是Oracle原生JSON处理的标记，说明没走索引，纯运行时解析 - 是否对JSON列用了函数索引但没命中（比如建了
JSON_VALUE(doc, '$.name' RETURNING VARCHAR2(100))索引，但SQL里写了UPPER(JSON_VALUE(...))） - 是否触发了隐式类型转换，比如把
JSON_VALUE(...)结果和NUMBER类型字段比较，导致索引失效
示例：WHERE JSON_VALUE(doc, '$.status') = 'active' 如果索引定义为 RETURNING VARCHAR2(10)，而实际值长度超10，就会退化为全表扫描+逐行解析。
ADDM建议里提到“Consider using function-based index”，但没说建在哪
19c的ADDM确实会泛泛提示“function-based index”，但它不会输出具体DDL。你得自己反推：
- 回到“SQL Statistics”页，找到目标SQL，点进详情，复制其WHERE或SELECT中完整的JSON函数调用，比如
JSON_VALUE(doc, '$.user.id' RETURNING NUMBER) - 确认该表达式是否确定性（deterministic）——
JSON_VALUE默认是，但加了ERROR ON ERROR或NULL ON ERROR也OK - 用这个表达式创建函数索引：
CREATE INDEX idx_json_user_id ON mytable (JSON_VALUE(doc, '$.user.id' RETURNING NUMBER)); - 注意：索引列不能超过数据库块大小限制，且
JSON_VALUE的RETURNING类型必须和查询中比较类型一致
ASH数据比AWR快照更能暴露JSON查询的瞬时压力
AWR每小时一次快照，而JSON查询可能集中在某个业务高峰的几分钟内爆发。这时单靠AWR会漏掉峰值——必须结合ASH。
在AWR报告里找“Top Sessions”或“Top SQL”章节下的“See ASH data for top sessions”链接（或直接查 v$active_session_history），按 sql_id 过滤，再看 program 和 event：
- 如果大量会话卡在
ON CPU，且sql_id对应JSON查询，说明是CPU解析瓶颈 - 如果出现
cursor: pin S wait on X，可能是共享池里JSON解析相关的游标争用（尤其在频繁硬解析时） - ASH里还能看到
plsql_entry，判断是否在存储过程中嵌套调用JSON函数，加剧了开销
最易忽略的一点：JSON解析消耗的是CPU时间，不是I/O等待，所以别盯着“Top I/O SQL”列表——它根本不会出现在那里。
