JSON_EXTRACT返回带引号的JSON格式字符串，需用JSON_UNQUOTE解包或CAST显式转换类型，路径错误时静默返回NULL，性能敏感场景应避免直接在WHERE中使用而改用生成列加索引。
JSON_EXTRACT 返回的是带引号的字符串，不是你想要的纯值
MySQL 的 JSON_EXTRACT 从不自动去掉外层双引号——哪怕提取的是字符串、数字或布尔值，结果都是 JSON 文本格式。比如 JSON_EXTRACT('{"name":"alice"}', '$.name') 返回 "\"alice\""（即带转义双引号的字符串），不是 "alice"。
这会导致常见错误：用在 WHERE 或 ORDER BY 里匹配失败、拼接时多出引号、跟整数比较返回 NULL。
- 提取数字时：
JSON_EXTRACT('{"age":25}', '$.age')得到"25"（字符串），不能直接和25比较 - 提取布尔值时：
JSON_EXTRACT('{"active":true}', '$.active')得到"true"（小写字符串），不是布尔类型TRUE - 在
IN子句中直接用会报错或逻辑错，因为类型不匹配
JSON_UNQUOTE 是解包必需步骤，但不能乱套
JSON_UNQUOTE 的作用就是剥掉 JSON_EXTRACT 外层的双引号和转义，把 JSON 字符串还原成常规 MySQL 值。但它只处理最外层引号，不解析嵌套结构，也不做类型转换。
典型正确用法是套在 JSON_EXTRACT 外面：JSON_UNQUOTE(JSON_EXTRACT(data, '$.name'))。但注意它对非字符串值（如 null、true、false）无效，会原样返回（JSON_UNQUOTE('null') 还是 'null' 字符串）。
- 对字符串字段必须用：
JSON_UNQUOTE(JSON_EXTRACT(...)) - 对数字字段，更稳妥的是用
CAST(... AS SIGNED)或CAST(... AS DECIMAL)显式转类型 -
JSON_UNQUOTE对NULL输入返回NULL，但对无效 JSON 路径返回NULL，容易掩盖路径写错的问题
JSON_EXTRACT 路径错误时静默返回 NULL，很难 debug
JSON_EXTRACT 遇到不存在的 key、错误的数组下标、或非法路径（如 $..foo 在旧版 MySQL 不支持），一律返回 NULL，不报错也不警告。你看到 NULL，可能是数据真为空，也可能是路径写错了。
调试建议优先用 JSON_VALID() 确认字段内容合法，再用 JSON_KEYS() 或 JSON_CONTAINS_PATH() 检查路径是否存在。
-
SELECT JSON_CONTAINS_PATH(data, 'one', '$.user.name') FROM t;返回 1 表示路径存在 -
SELECT JSON_KEYS(data) FROM t LIMIT 1;快速看顶层 key - 避免用
$..深度搜索（MySQL 5.7 不支持，8.0+ 才支持，且性能差）
性能敏感场景别在 WHERE 里反复 JSON_EXTRACT
每次调用 JSON_EXTRACT 都要解析整个 JSON 字段，如果在 WHERE 或 ORDER BY 中高频使用，会显著拖慢查询，尤其大表或复杂 JSON。
真实业务中，稳定字段（如 status、category）应该拆成普通列并加索引；临时分析可建生成列（Generated Column）+ 索引：
ALTER TABLE orders ADD COLUMN status VARCHAR(20) AS (JSON_UNQUOTE(JSON_EXTRACT(metadata, '$.status'))) STORED;
然后对 status 加索引。否则，WHERE JSON_EXTRACT(...) = 'done' 基本无法走索引。
MySQL 5.7+ 支持对 JSON 列建函数索引，但仅限于 JSON_EXTRACT + JSON_UNQUOTE 组合，且必须是确定性表达式；稍有偏差（比如加了 TRIM）就失效。
