Oracle 21c 原生 JSON 类型必须配合 IS JSON 约束、JSON_VALUE/JSON_QUERY 函数及 B-tree/GIN 索引才能避免性能退化；仅用 VARCHAR2 存 JSON 无法解析嵌套字段，且无语法校验；JSON 类型自动标准化格式、去重键，并不提供类似 PostgreSQL 的 JSONB 对应概念。
Oracle 21c 原生 JSON 类型不是“能用就行”，而是必须配合 IS JSON 约束、JSON_VALUE / JSON_QUERY 函数和 B-tree/GIN 类索引，否则性能会退化到字符串扫描级别。
为什么不能直接用 VARCHAR2 存 JSON 字符串
很多人把 JSON 当成普通文本塞进 VARCHAR2(4000) 或 CLOB，结果发现 WHERE name = '张三' 查不到嵌套字段里的值——因为数据库根本不知道那是个 JSON 结构。Oracle 21c 的 JSON 数据类型（注意：不是 JSON 列名，是类型名）会强制校验语法合法性，并启用后续所有原生函数支持。
-
INSERT INTO t (data) VALUES ('{"name":"张三"}')在data JSON列上会通过；换成VARCHAR2则完全不校验，哪怕插入'{name:"张三"'这种缺引号的垃圾也能成功 - 没有
JSON类型，JSON_VALUE(data, '$.name')会报ORA-40441: JSON syntax error，因为解析器无法信任输入格式 -
JSON类型列可被JSON_EXISTS、JSON_CONTAINS等谓词下推，而字符串列只能靠REGEXP_LIKE暴力匹配，无法走索引
JSON 与 JSONB 在 Oracle 里不存在对应概念
别被 PostgreSQL 的 JSONB 带偏——Oracle 21c 只有一个原生 JSON 类型，它内部已做二进制解析和规范化（类似 PostgreSQL 的 JSONB 行为），但不提供另一个“纯文本保留版”。也就是说：
Node.js 可靠编程
下载
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
- 你写入
'{"age": 32, "name": "张三"}'和'{ "age" : 32 , "name" : "张三" }'，查询结果完全一致，空格/换行/键序都被标准化了 - 重复键如
'{"id":1,"id":2}'会被自动去重，最终只保留最后一个值（"id":2） - 想保留原始格式（比如审计日志需记录客户端发来的原始字节流）？那就得用
CLOB+ 应用层自己解析，Oracle 不提供“JSON 原始镜像”类型
必须加 IS JSON 约束才能启用函数加速
仅声明列类型为 JSON 不够，必须显式加约束，否则优化器不会启用 JSON 谓词下推，JSON_VALUE 仍可能全表扫描。
ALTER TABLE users ADD CONSTRAINT chk_data_is_json CHECK (data IS JSON);
- 这个约束强制每次
INSERT/UPDATE都做 JSON 语法校验，代价极小（毫秒级），但换来的是整个 JSON 查询路径的可信度 - 没这句，
SELECT * FROM users WHERE JSON_VALUE(data, '$.status') = 'active'很可能退化为对每行调用函数再过滤 - 加上后，Oracle 能将该条件转为内部结构遍历，配合索引可做到毫秒级响应（百万级表实测
索引策略：B-tree 适合精确匹配，JSON_SEARCH 需要 FUNCTION-BASED 索引
Oracle 对 JSON 字段的索引不是开箱即用的 GIN，而是依赖函数索引 + 合理选型：
- 查单个字段值（如
status）：建FUNCTION-BASED B-TREE索引CREATE INDEX idx_users_status ON users (JSON_VALUE(data, '$.status')); - 查数组中是否存在某元素（如
hobbies包含'摄影'）：CREATE INDEX idx_users_hobbies ON users (JSON_QUERY(data, '$.hobbies' WITH ARRAY WRAPPER));
再配合JSON_EXISTS(data, '$.hobbies ? (@ == "摄影")') - 避免在
JSON_QUERY上建索引——它返回的是 JSON 片段（CLOB），B-tree 索引不支持 CLOB 全长比较，必须用JSON_VALUE提取标量值
最易被忽略的一点：Oracle 21c 的 JSON 函数默认区分大小写且严格匹配路径，'$.Name' 和 '$.name' 是两个不同键；如果源数据字段名不统一，得先用 JSON_MERGE_PATCH 或应用层清洗，否则索引和查询都会失效。
