mysql 5.7+ 需用 json_extract 或 ->> 提取 json 字段值再过滤，如 profile->>'$.role' = 'admin'；postgresql 用 -> 或 ->> 操作符查 jsonb 字段，配合 @> 或 json_contains 实现高效嵌套查询与索引优化。
MySQL 5.7+ 怎么用 JSON_EXTRACT 提取并过滤 JSON 字段
MySQL 原生支持 JSON 类型，但直接在 WHERE 中写 json_column.name = 'xxx' 会报错——JSON 字段不能用点号直接访问。必须用函数提取后再比较。
最常用的是 JSON_EXTRACT，它返回带引号的字符串（比如 "admin"），所以等值匹配时得加引号或用 ->> 操作符（自动去引号）：
SELECT * FROM users WHERE JSON_EXTRACT(profile, '$.role') = '"admin"';
更推荐写法（简洁且语义清晰）：
SELECT * FROM users WHERE profile->>'$.role' = 'admin';
-
->返回带双引号的 JSON 字符串，适合跟JSON_CONTAINS配合 -
->>自动去掉外层引号，返回纯字符串，适合跟普通字符串比较 - 路径表达式必须用单引号包裹，且以
$开头；嵌套字段用点号或数组下标，如'$.address.city'或'$[0].name'
PostgreSQL 怎么用 -> 和 ->> 操作符查 JSONB 字段
PostgreSQL 推荐用 JSONB 类型（存储更紧凑、支持索引），查询时用 ->（返回 jsonb）或 ->>（返回 text）：
SELECT * FROM orders WHERE data->>'status' = 'shipped';
注意：如果字段是 JSON（非 B），也能用同样操作符，但无法建 GIN 索引加速查询。
- 对
NULL值要小心：data->>'missing_key'返回NULL，所以WHERE data->>'role' = 'admin'会自动排除该行为NULL的记录 - 需要查嵌套对象里的布尔值？
data->'flags'->>'is_premium'得先转成布尔：(data->'flags'->>'is_premium')::boolean - 想查数组里是否包含某个值？用
JSONB_CONTAINS：WHERE data @> '{"tags": ["urgent"]}'
WHERE 中用 JSON_CONTAINS 判断 JSON 数组或对象是否存在
当你要查“某个 ID 是否在 JSON 数组里”或者“对象是否包含某键值对”，别硬拆字符串，用专门函数：
MySQL 示例（查 tags 数组中是否含 "vip"）：
SELECT * FROM products WHERE JSON_CONTAINS(tags, '"vip"', '$');
PostgreSQL 示例（查 metadata 是否包含 {"type": "api"}）：
SELECT * FROM endpoints
WHERE metadata @> '{"type": "api"}';
-
JSON_CONTAINS第三个参数是路径，默认'$'表示整个文档；数组需指定路径如'$.roles' -
@>是 PostgreSQL 的“包含”操作符，只适用于JSONB；左边是完整文档，右边是待匹配的子结构 - 这两个函数都支持索引（MySQL 的函数索引 / PG 的 GIN），但必须显式创建，否则全表扫描
容易忽略的坑：NULL、类型不一致和索引失效
JSON 字段查询慢，往往不是语法写错，而是掉进了这几个隐性陷阱：
-
profile->>'role'在字段为NULL或路径不存在时返回NULL，而NULL = 'admin'结果是UNKNOWN，整行被过滤掉——这有时是预期行为，有时是 bug 源头 - 数字类型容易误判：
'123'（字符串）和123（数字）在 JSON 里完全不同；JSON_EXTRACT返回字符串，CAST(... AS UNSIGNED)才能当数字比 - 写了
WHERE profile->>'age' > 18？看起来没问题，但 MySQL 不会自动把字符串转数字比较，实际走字典序（'100' 成立），必须显式转换：<code>CAST(profile->>'age' AS UNSIGNED) > 18 - 加了函数就默认没法用普通索引；MySQL 要建函数索引：
CREATE INDEX idx_role ON users ((profile->>'role'));；PG 要建 GIN 索引：CREATE INDEX idx_data_status ON orders USING GIN ((data->>'status'));
JSON 字段不是万能胶，查得多、过滤条件复杂、还要高性能，优先考虑拆成关系型字段；真要用 JSON，路径设计尽量扁平，避免多层嵌套，不然每次提取都多一层解析开销。
