postgresql中用jsonb_populate_recordset()解析json数组批量插入时，需确保目标表字段名与json键名严格一致且类型可隐式转换，缺失字段置null，not null约束会报错。
PostgreSQL 中用 jsonb_populate_recordset() 解析 JSON 数组批量插入
PostgreSQL 原生支持 JSON 批量导入，关键在于把 JSON 数组“摊平”成行集。如果源数据是形如 [{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}] 的字符串，不能直接 INSERT ... VALUES (...)，必须用 jsonb_populate_recordset() 配合一个已定义的复合类型或表结构。
常见错误是试图用 json_array_elements() 后再手动拼字段——它返回的是 jsonb 类型单列，无法直接映射到目标表字段；而 jsonb_populate_recordset() 要求目标表（或类型）字段名和 JSON 键名严格一致，且类型可隐式转换。
- 先确保目标表字段名与 JSON key 完全匹配（大小写敏感），例如 JSON 里是
"user_id"，表里就不能叫uid - 数值、布尔、null 值会被自动转换，但时间字符串（如
"2024-03-15T10:30:00Z"）需配合to_timestamp()在子查询中处理 - 如果 JSON 字段缺失，对应列将为 NULL —— 除非目标列有
NOT NULL约束，此时会报错ERROR: null value in column ... violates not-null constraint - 示例：
INSERT INTO users SELECT * FROM jsonb_populate_recordset(NULL::users, '[{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}]');
MySQL 8.0+ 用 JSON_TABLE() 实现等效解析
MySQL 没有类似 jsonb_populate_recordset() 的函数，但 JSON_TABLE() 是专为这类场景设计的：把 JSON 数组转为虚拟临时表。它比手动 JSON_EXTRACT() + 多层 UNION ALL 更可靠、更易读。
容易踩的坑是路径表达式写错：数组索引从 0 开始，但路径中要用 $[0] 这种形式；如果 JSON 是顶层对象而非数组，JSON_TABLE() 会报错 Invalid JSON path expression。
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
-
JSON_TABLE()第二个参数是列定义，语法为COLUMN (col_name TYPE PATH "$.key" [NULL | NOT NULL])，NOT NULL表示该字段必须存在，否则整行被丢弃 - 若 JSON 中某个对象缺少某 key，对应列值为 NULL —— 即使定义了
NOT NULL，也只影响该行是否保留，不会导致语句失败 - 性能上，
JSON_TABLE()在大数据量时比循环调用JSON_EXTRACT()快得多，但仍是全内存解析，单次不宜超过几 MB - 示例：
INSERT INTO users SELECT * FROM JSON_TABLE('[{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}]', "$[*]" COLUMNS (id INT PATH "$.id", name TEXT PATH "$.name")) AS jt;
SQL Server 使用 OPENJSON() 并显式指定 WITH 子句
SQL Server 的 OPENJSON() 默认返回三列（key、value、type），对批量插入毫无用处；必须加 WITH 子句才能映射成结构化结果。漏写 WITH 是最常导致“插进去全是 NULL”的原因。
另一个典型问题是类型不匹配：比如 JSON 里 "score": "95.5"（字符串），WITH 里定义为 score FLOAT 可以自动转换；但若写成 score INT，则值会被截断为 95，且无警告。
-
WITH中的路径区分大小写，"$.Name"和"$.name"是不同字段 - 嵌套对象需用点号展开，如
address_city NVARCHAR(50) '$.address.city'；数组需额外APPLY OPENJSON()嵌套处理 - 如果 JSON 数组元素结构不统一（有的有
email，有的没有），建议在WITH中全部声明为NVARCHAR，后续再用TRY_CAST()转换，避免运行时报错中断 - 示例：
INSERT INTO users SELECT * FROM OPENJSON(@json) WITH (id INT '$.id', name NVARCHAR(50) '$.name');
通用注意事项：字符集、空值与事务安全
无论用哪种数据库，原始 JSON 字符串本身若含非法 UTF-8 字节（比如从日志文件直接读取的脏数据），会导致整个 INSERT 语句失败，且多数数据库不提供“跳过坏行”选项。
批量插入不是原子操作的错觉很危险：MySQL 的 JSON_TABLE()、PostgreSQL 的 jsonb_populate_recordset() 都是在 INSERT 执行前完成解析，一旦中间某行触发约束冲突（如唯一键重复），整条 INSERT 就回滚——哪怕前面 999 行都成功了。
- 生产环境务必包裹在事务中，并捕获具体错误信息，而不是依赖
INSERT IGNORE或ON CONFLICT掩盖问题 - JSON 字符串建议先用
VALIDATE JSON（MySQL）、jsonb_valid()（PostgreSQL）或ISJSON()（SQL Server）预检，过滤掉明显损坏的数据 - 大体积 JSON（>10MB）不要直接传入 SQL 字符串，应改用客户端流式解析 + 分批
INSERT ... VALUES (),(),()，避免内存溢出或超长查询被 kill
