postgresql用jsonb_path_exists配合$.[*] ? (@.field == “value”)高效查json数组任意元素匹配，需jsonb类型和jsonb_path_ops索引；mysql用JSON_CONTaiNS或JSON_SEARCH；SQL Server用OPENJSON+WITH+TOP避免性能陷阱；禁用LIKE硬扫JSON字符串。
PostgreSQL 中用 jsonb_path_exists 查 JSON 数组任意元素匹配
PostgreSQL 12+ 原生支持路径表达式，查 JSON 数组中「任意一个元素包含某字段值」最高效的方式不是展开数组，而是用 jsonb_path_exists 配合 $[*] ? (@.field == "value") 这类存在性断言。
它底层走索引（需配合 jsonb_path_ops 索引），不生成中间行集，比 jsonb_array_elements + EXISTS 快一个数量级。
- 必须确保字段是
jsonb类型，json不支持该函数 - 路径表达式里
@指当前遍历元素，$[*]表示根数组所有项 - 字符串值要加双引号，数字不用：
@.status == "active"，不是@.status == active - 区分大小写，如需忽略，改用
lower(@.name) == "alice"
MySQL 8.0 用 JSON_CONTAINS 或 JSON_SEARCH 判断数组成员
MySQL 没有直接的「数组中任一对象含某键值对」语法，得组合函数。推荐优先用 JSON_CONTAINS——但它要求目标值本身是合法 JSON 值，且只能查「完全相等」；若查子字符串或模糊匹配，得 fallback 到 JSON_SEARCH。
-
JSON_CONTAINS(col, '"pending"', '$.statuses')：查statuses数组是否含字符串"pending"（注意外层引号） -
JSON_SEARCH(col, 'one', 'Error%', NULL, '$.logs[*].level')：在每个logs对象的level字段中模糊搜error%，返回首个匹配路径或NULL - 二者都支持
WHERE条件下推，但无法利用函数索引加速，建议对高频查询字段冗余普通列
SQL Server 用 OPENJSON + EXISTS 时避免性能陷阱
SQL Server 的 OPENJSON 默认把整个 JSON 数组展开成行集，如果数组很长、记录很多，EXISTS (select * FROM OPENJSON(...)) 容易触发大量临时行生成，拖慢查询。
- 务必加
WITH子句明确 schema，避免默认返回所有字段的开销 - 在
OPENJSON外层加TOP (1)，让引擎尽早短路：EXISTS (SELECT TOP (1) 1 FROM OPENJSON(...) WITH (state NVARCHAR(20) '$.state') WHERE state = 'failed') - 若 JSON 结构固定，考虑用计算列 + 持久化索引替代每次解析：
ALTER table t ADD status_list AS JSON_VALUE(data, '$.statuses') PERSISTED
通用避坑：别用 LIKE 或正则硬扫 JSON 字符串
看到 data LIKE '%"type":"admin"%' 这种写法就该警觉——它完全绕过 JSON 解析逻辑，既不可靠（字段顺序/空格/转义会破坏匹配），又无法使用任何索引，数据量一过万就明显卡顿。
- JSON 中的引号、反斜杠、换行都会导致
LIKE匹配失效 - 即使加了全文索引，也是对原始字符串建索，和语义无关
- 跨数据库迁移时，这种写法基本 100% 报错或行为不一致
真正难的不是写出能跑的 SQL，而是让 JSON 查询在 100 万行表里依然保持毫秒响应——这取决于你选的是语义解析路径，还是字符串暴力扫描路径。