MySQL插入JSON前必须验证格式有效性，推荐直接使用JSON类型列（如data JSON），由数据库自动校验并拒绝非法JSON（如尾随逗号、单引号），避免用VARCHAR/TEXT存储导致后续查询失败。
MySQL插入JSON前必须验证格式有效性
MySQL的JSON类型会拒绝非法JSON，但仅在INSERT时校验——如果用VARCHAR存，后续查询就可能因格式错误直接报错或返回NULL。所以不能跳过验证环节。
最稳妥的做法是：先用ISJSON()函数判断字符串是否合法，再插入；或者依赖JSON列类型自动拦截（推荐）。
-
CREATE TABLE logs (id INT PRIMARY KEY, data JSON)—— 声明列为JSON类型后，任何非法JSON都会被拒绝，如INSERT INTO logs VALUES (1, '{"key": "value",}')（末尾逗号）直接报错Invalid JSON text - 若表已存在且列是
TEXT或VARCHAR，可用SELECT ISJSON('{"a":1}') AS valid手动检查，返回1才继续插入 - 批量导入时，建议先用
LOAD DATA INFILE进临时表（TEXT列），再用INSERT ... SELECT+WHERE ISJSON(col)=1过滤合法数据
SQL Server中插入JSON要确保兼容性级别≥130
SQL Server 2016+才支持JSON函数，但前提是数据库兼容性级别至少为130。否则JSON_VALUE、ISJSON等函数全部不可用，INSERT时也不会校验JSON格式。
检查方式：SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME()；升级命令：ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 150（推荐150，兼容最新功能）。
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 即使列类型是
NVARCHAR(MAX)，也必须靠ISJSON()显式校验，例如：INSERT INTO logs SELECT payload FROM raw_json WHERE ISJSON(payload) = 1 - 不要依赖客户端拼接JSON字符串后直接INSERT——特殊字符（如单引号、换行）未转义会导致语法错误或注入风险
- 若JSON含二进制数据（如Base64图片），应改用
VARBINARY单独存储，而非塞进JSON字段
PostgreSQL用jsonb比json更安全高效
jsonb在写入时自动去重键、标准化空格、解析并二进制存储，天然排除无效JSON；而json只是字符串校验，保留原始格式，查询时仍需解析。
实际插入时，jsonb列对非法输入同样报错，且支持GIN索引加速路径查询——这是json做不到的。
- 建表优先选
data JSONB NOT NULL，而非JSON - 插入时用
INSERT INTO logs VALUES (1, '{"level":"INFO","msg":"ok"}'::jsonb)，类型强制转换可提前暴露格式问题 - 避免用
to_json()函数包裹非JSON值（如to_json(123)生成数字而非对象），容易导致下游解析逻辑断裂
跨数据库通用陷阱：时间与嵌套数组处理不一致
不同数据库对JSON中时间字符串、深层嵌套数组的提取行为差异极大，直接INSERT后查询可能“看似成功，实则丢数据”。
比如{"ts": "2024-03-15T10:22:00Z"}在MySQL用j->>'$.ts'取出来是字符串，在SQL Server用JSON_VALUE(j, '$.ts')也是字符串，但PostgreSQL的data->>'ts'同样不自动转类型——全都需要手动CAST或函数转换。
- 时间字段务必在INSERT前标准化为ISO 8601格式（
YYYY-MM-DDTHH:MM:SSZ），避免"2024/03/15"这类区域格式引发解析失败 - 嵌套数组如
"tags": ["a","b"]，MySQL用JSON_CONTAINS()查，SQL Server用OPENJSON()展开，PostgreSQL用jsonb_array_elements()——不能指望同一段SQL到处运行 - 空值处理：
NULL在JSON里是合法值，但某些ORM或ETL工具会把它转成"null"字符串，导致ISJSON()返回1却实际不是有效JSON
json/jsonb选择不当拖慢查询——这些细节不提前踩一遍，上线后就是半夜告警。 
