MySQL 8.0+ 用 JSON_EXTRACT 按路径提取 JSON 字段，返回带引号字符串；推荐用 ->> 获取无引号值；PostgreSQL 用 -> 和 ->> 或 #>> 实现类似功能，注意 NULL 安全与大小写敏感。
MySQL 8.0+ 怎么用 JSON_EXTRACT 取出嵌套字段
直接上手：只要字段类型是 JSON（或合法 JSON 字符串的 TEXT），就能用 JSON_EXTRACT 按路径取值。它不自动类型转换，返回的是带引号的 JSON 片段（比如 "admin" 而不是 admin）。
常见错误现象：JSON_EXTRACT(user_info, '$.role') 返回 "\"admin\""（双转义），导致 = 'admin' 匹配失败；或者路径写成 '$.roles[0]' 却忘了数组下标从 0 开始，而数据里 roles 是空数组或根本不存在。
- 路径表达式必须用单引号包裹，且以
$开头，例如'$.address.city'、'$.tags[1]' - 如果不确定字段是否存在，加
JSON_VALID()做前置判断，避免整行被过滤掉：WHERE JSON_VALID(user_info) AND JSON_EXTRACT(user_info, '$.status') = '"active"' - 想省去引号，用
->>操作符替代（MySQL 5.7+）：user_info ->> '$.role'直接返回 unquoted 字符串
PostgreSQL 怎么对应实现？别硬套 JSON_EXTRACT
PostgreSQL 没有 JSON_EXTRACT，但有更灵活的原生支持。核心是 ->（返回 JSON）和 ->>（返回 text），配合 #>>（路径数组语法）。
使用场景：比如字段叫 payload，存的是 {"data": {"id": 123, "meta": {"ts": 1712345678}}}，要取 meta.ts：
-
payload -> 'data' -> 'meta' ->> 'ts'—— 链式调用，最常用 -
payload #>> '{data,meta,ts}'—— 等价写法，路径用数组字面量，适合动态拼接 - 注意：如果任意一级 key 不存在，
->返回NULL，不会报错；但->>对NULL输入也返回NULL，所以可用于安全判空
JSON_EXTRACT 在 WHERE 条件里为什么查不出数据？
多数时候不是语法错，而是类型或结构不匹配。典型表现：明明 JSON 字段里有 "is_deleted": false，但 WHERE JSON_EXTRACT(meta, '$.is_deleted') = 'false' 查不到。
- JSON 中的
false是布尔字面量，不是字符串，得写成JSON_EXTRACT(meta, '$.is_deleted') = FALSE（MySQL）或用IS FALSE - 嵌套对象中字段名大小写敏感，
'$.UserId'≠'$.userid'，别靠猜 - 数组元素查询容易漏掉
JSON_CONTAINS：想查 “tags 包含 'vip'”，别写JSON_EXTRACT(tags, '$[0]') = '"vip"'，改用JSON_CONTAINS(tags, '"vip"') - 性能影响：在
WHERE里对 JSON 字段做JSON_EXTRACT无法走索引，大数据量务必考虑生成列 + 索引（MySQL）或jsonb_path_ops索引（PostgreSQL）
JSON 字段更新比查询更危险，JSON_SET 和 JSON_REPLACE 别混用
这两个函数看着像，行为却关键不同：前者是“无则增、有则改”，后者是“仅改已有字段，新增字段直接忽略”。线上误用会导致字段莫名消失。
- 想确保
status字段存在并设为"pending"，用JSON_SET(data, '$.status', 'pending') - 如果只想更新已存在的
updated_at，且不想意外添加新 key，才用JSON_REPLACE(data, '$.updated_at', NOW()) - PostgreSQL 对应是
jsonb_set()，但它的第四个参数默认true（即“不存在就创建”），设为false才等效于JSON_REPLACE - 所有 JSON 修改函数都不支持原地更新，必须配合
UPDATE ... SET field = JSON_SET(field, ...)，漏写field =就变成清空字段
{"price": "99.9"}（字符串），后端又没统一转 number，后续数值计算或排序就会出错——这种问题不会在 SQL 层暴露，得靠应用层约束或生成列做类型固化。 
