sql server 2016+ 使用 for json 子句直接返回 json,它不是函数而是查询子句,必须紧跟 select 后;for json auto 自动推导层级,for json path 支持点号嵌套(如 user.name),null 默认被忽略,需加 include_null_values 才输出 null。

SQL Server 2016+ 怎么用 FOR JSON 直接返回 JSON?
SQL Server 2016 起原生支持 JSON,FOR JSON 是最轻量、最直接的方案。它不是函数,而是查询子句,必须紧跟在 SELECT 后面,不能单独用在变量赋值或 RETURN 中。
常见错误是写成 SELECT ... FOR JSON PATH 然后试图把结果塞进 RETURN ——RETURN 只接受整数,JSON 必须作为结果集返回。
- 用
SELECT @json = (SELECT ... FOR JSON PATH)提前拼好字符串(适合单行 JSON) - 但更推荐直接
SELECT ... FOR JSON PATH,让客户端接收结果集(兼容性更好,不丢失嵌套结构) -
FOR JSON AUTO自动按表名/别名推导层级,适合简单 JOIN;FOR JSON PATH更灵活,能用点号控制嵌套,比如user.name、address.city - 注意 NULL 值默认被忽略,加
INCLUDE_NULL_VALUES才输出"field": null
MySQL 8.0 怎么用 JSON_OBJECT 和 JSON_ARRAYAGG 拼 JSON?
MySQL 没有类似 FOR JSON 的查询级语法,得靠函数组合。核心是:JSON_OBJECT 构建单对象,JSON_ARRAYAGG 聚合多行成数组,两者嵌套使用。
容易踩的坑是字段别名没加引号或用了保留字,导致 JSON_OBJECT 报错 ERROR 3142;还有聚合时漏写 GROUP BY,让 JSON_ARRAYAGG 把所有行压成一个数组(而不是每组一个)。
- 单行:
SELECT JSON_OBJECT('id', id, 'name', name) FROM user WHERE id = 123 - 多行列表:
SELECT JSON_ARRAYAGG(JSON_OBJECT('id', id, 'name', name)) FROM user - 带关联:先
JOIN再GROUP BY parent.id,然后在外层用JSON_OBJECT包住JSON_ARRAYAGG(child.*) - 性能注意:大结果集下
JSON_ARRAYAGG可能触发group_concat_max_len限制,默认只有 1024 字符,需提前设高(如SET SESSION group_concat_max_len = 1000000)
PostgreSQL 怎么用 row_to_json 和 json_agg?
PostgreSQL 的 JSON 支持最成熟,但函数语义和 MySQL 不同:row_to_json 作用于单行(或子查询结果),json_agg 是聚合函数,对应 MySQL 的 JSON_ARRAYAGG。
使用 JSON Schema 验证 JSON 数据,从示例 JSON 生成 schema,并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
典型错误是把 row_to_json(t.*) 直接放在 SELECT 列表里又没加 GROUP BY,导致“column must appear in the GROUP BY clause” —— 实际上你并不总需要 GROUP BY,除非用了聚合函数。
- 单行:
SELECT row_to_json(t.*) FROM (SELECT id, name FROM user LIMIT 1) t - 多行数组:
SELECT json_agg(row_to_json(t.*)) FROM (SELECT id, name FROM user) t - 嵌套结构:用子查询 +
json_build_object控制键名,比如json_build_object('user', row_to_json(u.*), 'posts', (SELECT json_agg(row_to_json(p.*)) FROM post p WHERE p.user_id = u.id)) - 注意:
row_to_json默认包含 NULL 字段,无需额外开关;但若列含二进制或特殊类型(如bytea),需先转成文本或 base64
存储过程中怎么安全返回 JSON 而不截断?
无论哪种数据库,存储过程返回 JSON 最容易出问题的地方不是语法,而是长度限制和字符集。
SQL Server 的 varchar(max) 或 nvarchar(max) 看似够用,但实际执行时如果没显式声明类型,可能被隐式转成 varchar(8000) 导致截断;MySQL 的 group_concat_max_len 和 PostgreSQL 的 work_mem 都会影响大 JSON 生成。
- SQL Server:声明变量时务必写
DECLARE @json nvarchar(max),别只写nvarchar - MySQL:在存储过程开头加
SET SESSION group_concat_max_len = 4194304;(4MB) - PostgreSQL:避免在函数里拼超大 JSON,优先用
RETURN QUERY SELECT ...让客户端流式接收 - 统一建议:别在存储过程里做复杂 JSON 格式化,尤其涉及循环拼接 —— 容易失控,交给应用层更可控
真正麻烦的从来不是“怎么生成 JSON”,而是“怎么保证生成的 JSON 不被悄悄截掉、不因字符集乱码、不在某次数据量上涨后突然失败”。这些边界条件,比语法本身更值得盯紧。










