AWR报告不直接标识JSON查询慢，需通过DB Time、CPU Time、Buffer Gets等指标反推：高CPU多因JSON路径解析与类型转换，高逻辑读源于未索引JSON列全LOB读取，高执行次数反映积少成多型负载，根因常在缺失IS JSON约束、虚拟列或函数索引。
AWR报告里根本不会直接标出“JSON查询慢”
oracle awr不识别json_exists、json_value这些函数是否在执行，它只统计底层资源消耗。所谓“json查询慢”，实际是这些函数触发的cpu计算、内存拷贝、lob访问或全表扫描被放大了。你得从报告中反推：哪些sql吃了最多db time，再人工确认它们是否含json操作。
常见误判点：
- 看到
DB CPU占比高就以为是JSON解析慢——也可能是JSON_TABLE展开嵌套数组时做了大量字符串切分和类型转换 - 把
buffer busy waits归因于JSON列——其实是因为IS JSON约束校验时频繁访问索引块，或虚拟列索引未建导致回表 - 忽略
PGA memory峰值：JSON路径解析（尤其带过滤的JSON_EXISTS('$?(@.status == "done")')）会临时分配大量内存，可能触发sorts (memory)溢出到磁盘
查“JSON相关SQL”必须盯紧三个AWR表格
不要在SQL ordered by Elapsed Time里盲目翻页。先定位可能含JSON操作的SQL ID，再交叉验证：
-
SQL ordered by Gets：JSON字段若没建虚拟列或函数索引，JSON_EXISTS(json_col, '$.id')会强制对每行做全LOB读取，逻辑读飙升 -
SQL ordered by Executions：高频调用JSON_VALUE(json_col, '$.config.timeout')的小语句，单次快但总耗时冲进Top 5——这是典型的“积少成多”型JSON负载 -
SQL ordered by Parse Calls：如果某条含JSON_TABLE的SQL解析次数异常高，说明绑定变量没用好，每次都在硬解析JSON路径表达式
示例：一条SQL ID为abc123xyz的语句在Elapsed Time(s)排第2，Executions为8400，Elap per Exec(s)仅0.012，但Buffer Gets高达2.1M——基本可断定它在反复扫描一个未索引的JSON列。
JSON_TABLE性能问题在AWR里暴露最明显
JSON_TABLE是AWR里最容易被误读为“普通JOIN”的重灾区。它本质是运行时动态构建结果集，不走传统执行计划缓存路径。关键看两点：
- 报告中
SQL ordered by CPU Time里该SQL的CPU占比是否远超IO占比——高CPU意味着JSON路径解析、类型转换、嵌套展开开销大 - 对比
DB Time和Elapsed Time：若两者接近且远大于CPU Time，说明大量时间花在等待（比如PGA memory分配锁或direct path read temp），很可能是NESTED子路径展开时数据量过大
避坑提示：
- 别在
JSON_TABLE外层再套ORDER BY或GROUP BY——AWR会显示sorts (disk)暴增，因为整个JSON展开结果集要落地排序 - 用
NESTED展开数组时，若Executions列显示1但Rows Processed超10万，说明单次调用膨胀严重，应考虑改用物化虚拟列+索引
真正要检查的不是SQL，而是底层对象设计
AWR报告只是症状，根因往往在表结构。生成报告后立刻查这几项：
- 确认JSON列是否有
IS JSON约束：SELECT constraint_name FROM user_constraints WHERE search_condition_vc LIKE '%IS JSON%'——没有的话，每次JSON_EXISTS都要做完整语法校验，CPU白耗 - 查虚拟列是否建了索引：
SELECT column_name FROM user_tab_cols WHERE virtual_column = 'YES' AND table_name = 'YOUR_TABLE'，再查user_indexes对应索引是否存在 - 检查
DBA_HIST_SEG_STAT中该表的logical_reads_total是否持续高于同类非JSON表——如果是，说明JSON列正在拖垮整个段的缓存效率
最常被忽略的一点：JSON_TABLE引用的路径若含通配符（如'$.items[*].price'），AWR里看不出区别，但实际执行时会触发全数组遍历，这种开销在快照周期内会被均摊，导致Elap per Exec(s)看起来正常，实则不可扩展。
