MySQL 5.7+ 中用 JSON_CONTAINS 查询含特定键值对的记录，需传入合法 JSON 值（如 JSON_OBJECT('status','active')）作为第二个参数，不指定路径时默认匹配顶层对象；若指定路径（如 '$.status'），则可传标量值如 '"active"'。
MySQL 5.7+ 怎么用 JSON_CONTAINS 查含特定键值对的记录
MySQL 原生 JSON 支持不是“查 JSON 字段里有没有某个 key”，而是得把整个键值对当作原子单元匹配。比如要找 info 字段中 {"status": "active", "type": "user"} 的某一部分，不能只写 status = 'active' 就完事——得构造合法 JSON 值参与比对。
常见错误是直接拼字符串传给 JSON_CONTAINS，结果返回空：因为第二个参数必须是 JSON 值（用 JSON_OBJECT 或 CAST(... AS JSON) 构造），且第三个参数（路径）不填时默认匹配顶层对象。
-
JSON_CONTAINS(info, JSON_OBJECT('status', 'active'))✅ 正确：构造 JSON 对象再匹配 -
JSON_CONTAINS(info, '{"status": "active"}')⚠️ 看似可行，但若字段含多余空格或 key 顺序不同，可能失败（MySQL 8.0.17+ 才保证结构等价性） -
JSON_CONTAINS(info, '"active"', '$.status')✅ 更精准：指定路径，值可为标量
PostgreSQL 怎么用 @> 操作符查嵌套 JSONB 键值对
PostgreSQL 的 jsonb 类型支持高效索引和包含查询，@> 是“是否包含”操作符，右边必须是合法 jsonb 值，且结构需完全匹配（对象键值对子集即可，不要求全等）。
容易踩的坑是忘记类型转换：文本字面量默认是 text，必须显式转 jsonb，否则报错 operator does not exist: jsonb @> text。
-
data @> '{"status": "active"}'::jsonb✅ 路径无关，只要顶层有该键值对 -
data @> '{"tags": ["vip"]}'::jsonb✅ 数组也支持，但注意数组内容需完全一致（顺序、元素数） -
data @> '{"profile": {"age": 25}}'::jsonb✅ 支持多层嵌套，但不能跨层级模糊匹配（如只查age = 25不指定profile路径就不行）
SQL Server 怎么用 OPENJSON 提取后过滤 JSON 字段
SQL Server 没有原生 JSON 包含运算符，得先解析再筛选。核心是 OPENJSON 把 JSON 字符串展开成行集，配合 WITH 子句定义 schema，才能按列过滤。
关键点在于：如果 JSON 结构不固定（比如 attributes 下 key 名动态），就不能硬写 WITH (status NVARCHAR(20) '$.status')；得先用无 schema 模式提取所有键值，再用 WHERE [key] = 'status' AND value = 'active' 过滤——但这会丧失索引能力，性能差。
- 结构已知时，优先用
WITH显式声明字段：SELECT * FROM OPENJSON(@json) WITH (status NVARCHAR(20) '$.status') WHERE status = 'active' - 结构未知时，用两层
OPENJSON：外层解析对象，内层解析每个 value（若 value 是对象或数组），再加条件判断 - 别忘了
ISJSON()预检：避免解析失败中断查询，例如WHERE ISJSON(data) = 1 AND ...
通用陷阱：NULL、类型不一致与索引失效
所有数据库在 JSON 查询中都容易因数据质量翻车。比如 MySQL 中 JSON_CONTAINS(NULL, ...) 返回 NULL（不是 FALSE），导致 WHERE 条件过滤掉整行；PostgreSQL 里 jsonb @> NULL 直接报错。
另一个隐形杀手是类型隐式转换：MySQL 把字符串 '123' 和数字 123 当不同值，PostgreSQL 的 jsonb 严格区分 "123"（字符串）和 123（数字）。查不到别急着怀疑语法，先 SELECT JSON_TYPE() 或 pg_typeof() 看实际存的是啥。
- MySQL：用
JSON_EXTRACT(info, '$.status')+CAST(... AS CHAR)统一转字符串再比 - PostgreSQL：用
(data->>'status') = 'active'强制取字符串，避开类型歧义 - 所有场景：JSON 字段建普通 B-tree 索引无效，必须用生成列（MySQL）或表达式索引（PostgreSQL）加速
实际业务中，JSON 查询慢往往不是语法问题，而是没意识到“每次调用 JSON_CONTAINS 都要解析整段 JSON 字符串”。真要高频查某个 key，不如拆成独立字段存，或者用生成列持久化提取结果。
