SQL Server 2022 中 JSON_PATH_EXISTS 不支持带过滤器的路径（如 $?(@.grade>5)），仅支持基础路径；需用 OPENJSON 展开嵌套数组并配合 WHERE 筛选，多层嵌套须逐级调用 OPENJSON。
JSON_PATH_EXISTS 不能直接查嵌套数组元素值
SQL Server 2022 的 JSON_PATH_EXISTS 只返回布尔值（1 或 0），不提取内容。想查“某个嵌套数组里是否存在满足条件的元素”，得用 OPENJSON 配合 WHERE，而不是依赖路径函数本身返回数据。
常见错误现象：SELECT JSON_PATH_EXISTS(doc, '$.children[?(@.grade > 5)]') 看似合理，但该函数在 2022 中不支持带过滤器的 SQL/JSON 路径（如 [?(@.grade > 5)]），会报错 Invalid JSON path expression —— 这个语法是 SQL Server 2025 预览版才支持的。
- 2022 中能用的路径仅限基础结构：如
$.children[0].grade、$.children[1].pets[0].givenName - 带过滤器的路径（
[?(@.xxx)]）或通配符（[*]）在 2022 中无效，强行使用会触发解析失败 - 若需条件匹配，必须先用
OPENJSON展开数组，再用 T-SQL 过滤
用 OPENJSON 展开 children 数组并关联父级字段
处理类似 {"children": [{"givenName":"Jesse","grade":1}, {"givenName":"Lisa","grade":8}]} 这类结构时，不能只靠 JSON_VALUE 提取单个位置的值；必须把数组“摊平”成行集才能做条件筛选或聚合。
实操要点：
- 第一层
OPENJSON(@json, '$.children')返回每个 child 为一行，key是索引，value是子对象 JSON 字符串 - 对
value再套一层OPENJSON，就能提取givenName、grade等字段 - 外层查询需用
WITH显式定义列名和类型，否则所有字段都是nvarchar(max) - 别漏掉
AS json别名，否则第二层OPENJSON无法引用上层展开结果
示例：
DECLARE @json NVARCHAR(MAX) = N'{
"id": "DesaiFamily",
"children": [
{"givenName": "Jesse", "grade": 1, "gender": "female"},
{"givenName": "Lisa", "grade": 8, "gender": "female"}
]
}';
<p>SELECT
f.id,
c.givenName,
c.grade
FROM OPENJSON(@json) WITH (
id NVARCHAR(100) '$.id',
children NVARCHAR(MAX) AS JSON
) AS f
CROSS APPLY OPENJSON(f.children)
WITH (
givenName NVARCHAR(50) '$.givenName',
grade INT '$.grade',
gender NVARCHAR(10) '$.gender'
) AS c
WHERE c.grade > 5;处理多层嵌套（如 children → pets）必须嵌套 OPENJSON
当 JSON 中存在“数组套数组”结构（如每个 child 有多个 pets），不能用单层路径如 $.children[0].pets[0].givenName 批量提取——那只能取固定下标，无法泛化。
正确做法是逐级展开：
- 先用
OPENJSON展开children数组，得到 child 行集 - 对每一行的
pets字段（本身是 JSON 数组字符串），再调一次OPENJSON - 第二层
WITH中定义pet_name NVARCHAR(50) '$.givenName'，即可拿到每只宠物名 - 若某 child 没有
pets字段或值为null，CROSS APPLY会跳过该 child；要用OUTER APPLY保留空 pets 的记录
关键细节：第二层 OPENJSON 的输入必须是字符串类型（NVARCHAR），所以第一层 WITH 中 pets 列必须声明为 AS JSON 或 NVARCHAR(MAX)，不能写成 JSON 类型（SQL Server 2022 不支持原生 json 类型）。
性能与可读性平衡：避免三层以上 OPENJSON 嵌套
展开深度超过两层（如 family → children → pets → toys）会让 SQL 变得难维护，且执行计划中嵌套循环增多，影响性能。
更可控的做法：
- 把中间层结果存入临时表（
#children），加索引后供后续 JOIN 使用 - 用
JSON_QUERY提前截取子结构（如JSON_QUERY(doc, '$.children')），再对临时字段展开，减少重复解析 - 确认业务是否真需要全部嵌套数据：有时只需统计 pets 数量，用
LEN(children) - LEN(REPLACE(children, '"givenName"', ''))这类字符串技巧反而更快（但不可靠，仅作备选） - 2022 中没有
JSON_CONTAINS对数组元素的高效判断，所以不要试图用它替代展开逻辑
最易被忽略的一点：所有 OPENJSON 调用都依赖输入字符串是合法 JSON，务必在上游用 ISJSON() 校验，否则遇到格式错误数据会直接中断整个查询。
