MySQL 8.0 实现 JSON 真正可用：支持路径索引、JSON_TABLE 表连接、JSON_MERGE_PATCH 差异更新及严格校验；5.7 仅支持基础解析，需冗余生成列且无法直接索引路径，复杂查询性能差。
JSON 字段在 MySQL 5.7 是“能存”，到了 8.0 才真正“能查、能索、能联、能聚合”。
MySQL 5.7 的 JSON 字段本质是“带校验的字符串”
它提供 JSON_EXTRACT()、->、JSON_CONTAINS() 等基础函数，但所有操作都在运行时解析整个 JSON 文本——每次查询都要重新解析，无法利用 B+ 树索引加速路径查找。
想按 profile->'$.email' 快速检索？必须绕路：
- 定义一个
STORED生成列（VIRTUAL列在 5.7 不可索引） - 手动
JSON_UNQUOTE(JSON_EXTRACT(profile, '$.email'))提取并存储 - 再对这个生成列建普通索引
- 查询时还得显式写成
WHERE email = 'x@y.z'，不能直接写WHERE profile->'$.email' = 'x@y.z'
稍一嵌套或条件变复杂（比如查 tags 数组是否包含某个值），就得靠 JSON_CONTAINS() 全表扫描，性能断崖式下跌。
MySQL 8.0 支持 JSON 表达式索引，路径可直接索引
这是最实在的飞跃：你终于可以对 JSON 内部路径建索引，且语法直白。
例如：
CREATE INDEX idx_user_email ON users (CAST(profile->'$.email' AS CHAR(255)));
注意几个关键点：
-
CAST(... AS CHAR)是必须的——InnoDB 只支持对标量类型建索引，不能直接索引JSON类型本身 - 索引生效后，
WHERE profile->'$.email' = 'x@y.z'就能走索引，EXPLAIN显示type=ref - 支持多路径联合索引，比如
(CAST(profile->'$.status' AS CHAR), CAST(profile->'$.created_at' AS DATETIME)) - 不依赖生成列，减少冗余字段和 DDL 复杂度
而 5.7 做同样事，得加一列、建索引、改查询逻辑——8.0 把这三步压成一条 CREATE INDEX。
MySQL 8.0 新增 JSON_TABLE()，让 JSON 变成“可 JOIN 的表”
5.7 完全没法把 JSON 数组展开成行集；遇到 {"items": [{"id":1},{"id":2}]} 这种结构，只能靠应用层解析或写恶心的递归自连接模拟。
8.0 的 JSON_TABLE() 直接解决：
SELECT u.id, jt.id AS item_id FROM users u, JSON_TABLE(u.profile, '$.items' COLUMNS (id INT PATH '$.id')) AS jt WHERE jt.id > 0;
这意味着：
- JSON 数组可被当作派生表参与
JOIN、GROUP BY、窗口函数 - 支持多级嵌套路径映射（
COLUMNS里还能嵌套NESTED PATH） - 配合
JSON_ARRAYAGG()反向聚合，实现 JSON ↔ 关系型双向自由转换
5.7 没这能力，硬做就是拼字符串 + 应用层兜底，极易出错且不可维护。
别忽略：8.0 的 JSON_MERGE_PATCH() 和校验更严格
5.7 的 JSON_SET() / JSON_INSERT() 是“覆盖式”更新，容易误删字段；8.0 引入 JSON_MERGE_PATCH() 实现 RFC 7396 语义——只合并差异，保留原 JSON 中未提及的字段。
例如：
SELECT JSON_MERGE_PATCH('{"a":1,"b":2}', '{"b":3,"c":4}');结果是 {"a": 1, "b": 3, "c": 4}，而不是 5.7 的 JSON_SET() 那种需要逐个路径指定的笨拙写法。
另外，8.0 对 JSON 格式校验更严格（比如拒绝尾随逗号、反对重复 key），上线前就能暴露前端传来的脏数据，而不是等查询时报错才暴露。
真正麻烦的不是语法多几个函数，而是当 JSON 字段开始承担业务主干逻辑（如权限配置、动态表单、用户画像）时，5.7 的“半吊子支持”会迅速变成运维黑洞——索引难建、分析难写、变更难测。8.0 把这些坑填平了，但前提是你的查询真用到了深度路径访问或数组展开，否则升级收益不明显。
