Oracle 19c JSON列必须声明为JSON类型并配合RETURNING显式指定返回类型，否则无法启用自动类型映射、索引下推和数值运算；已有表需通过ADD-UPDATE-DROP迁移，且JSON_TABLE是唯一支持数组展开与类型绑定的方式。
Oracle 19c JSON列必须用 JSON 约束，不能只靠 IS JSON 检查
很多人以为在 create table 里加个 check (col is json) 就能当 json 列用，其实不行——这只能做插入校验，不触发 oracle 内置的 json 自动类型映射（比如把 {"id": 123} 的 id 当数字处理）。真要启用自动映射，必须显式声明列类型为 json：
CREATE TABLE orders ( id NUMBER, payload JSON );
这样 Oracle 才会启用 JSON 值的内部结构感知，后续用 $. 路径访问时才能正确推导字段类型、支持函数下推（如 JSON_VALUE(payload, '$.amount' RETURNING NUMBER) 直接走索引）。
常见错误现象：JSON_VALUE 返回字符串而非数字，JSON_TABLE 报 ORA-40478，或谓词无法下推导致全表扫描。
-
JSON类型列要求 Oracle 19c+ 且兼容级别 ≥ 19.0（检查V$VERSION和COMPATIBLE参数） - 如果已有表，不能直接
ALTER COLUMN ... TYPE JSON，得先ADD新列 →UPDATE迁移 →DROP旧列 - 从 19c 开始，
JSON类型列默认启用严格模式（STRICT），非法 JSON 会直接拒绝插入，不像IS JSON那样容忍空格/注释
自动类型映射依赖 RETURNING 显式声明，不是“智能推断”
Oracle 不会根据 JSON 内容自动决定返回什么 SQL 类型。哪怕你存的是 {"price": 99.99}，JSON_VALUE(payload, '$.price') 默认返回 VARCHAR2(4000)，不是 NUMBER。必须写明 RETURNING：
SELECT JSON_VALUE(payload, '$.price' RETURNING NUMBER) AS price_num FROM orders;
否则所有数值都当字符串处理，排序、比较、索引都会出错（比如 '10' > '9' 成立，但数值上是错的）。
使用场景：报表取值、JOIN 条件、WHERE 中范围查询（JSON_VALUE(...) > 100）。
-
RETURNING支持NUMBER、DATE、TIMESTAMP、VARCHAR2(n)，不支持BOOLEAN（JSON boolean 在 Oracle 中只能转成VARCHAR2或用JSON_EXISTS判断） - 若 JSON 字段可能为空或缺失，加
NULL ON ERROR（默认行为），避免报ORA-40476 - 性能影响：带
RETURNING NUMBER的表达式可被函数索引覆盖；纯字符串返回则无法利用数值索引
JSON_TABLE 是唯一支持“展开 JSON 数组 + 自动类型绑定”的方式
想把 {"items": [{"qty": 2}, {"qty": 5}]} 展开成两行，并让 qty 直接是数字？不用自己 REGEXP_SUBSTR 解析。用 JSON_TABLE + COLUMNS 子句明确类型即可：
SELECT jt.qty
FROM orders,
JSON_TABLE(payload, '$.items[*]'
COLUMNS (qty NUMBER PATH '$.qty')
) jt;
这里 qty NUMBER PATH 就是自动类型绑定的关键——它不只是转换，还让优化器知道该列可参与数值运算和索引。
容易踩的坑：
- 路径必须用
$.*或$.[*]形式，不能漏掉[*]（否则只返回一行，数组被当整体） -
COLUMNS里不写NUMBER，结果仍是字符串；写错类型（如用DATE解析非日期字符串）会报ORA-40494 - 如果 JSON 结构不固定（有的有
qty，有的没有），加MISSING ON ERROR，否则整行丢失
JSON 函数性能瓶颈常藏在隐式类型转换里
看起来一样的 SQL，执行计划却一个走索引一个全表扫描？大概率是 RETURNING 类型没对齐。比如建了函数索引：CREATE INDEX idx_price ON orders (JSON_VALUE(payload, '$.price' RETURNING NUMBER));，但查询时写成 JSON_VALUE(payload, '$.price') > 100（缺 RETURNING），Oracle 就没法复用这个索引。
另一个隐形坑：NLS 设置影响字符串比较。如果 JSON 里存的是 "status": "active"，而你用 JSON_VALUE(... RETURNING VARCHAR2(10)) = 'active'，但数据库字符集是 AL32UTF8、客户端是 WE8MSWIN1252，就可能因排序规则不一致导致索引失效。
- 始终在函数索引定义和查询中保持
RETURNING类型、长度、字符语义（VARCHAR2(10 CHAR)vsVARCHAR2(10 BYTE)）完全一致 - 用
DBMS_JSON.HAS_VALIDATION检查 JSON 列是否启用了验证（影响解析开销） - 19c 的 JSON 解析默认开启
STRICT，比宽松模式慢约 10–15%，但换来了类型安全——别为了省这点时间关掉它
真正麻烦的从来不是怎么写第一行 JSON 查询，而是当业务开始依赖 JSON_VALUE 做 WHERE 条件、当数据量涨到千万级、当不同团队往同一个 JSON 字段塞不同结构时，类型声明和索引对齐才显出分量。
