mysql 5.7.8+原生支持json类型和基础函数（如json_extract、json_set），但不支持部分更新和函数索引，需通过生成列+stored+索引三步实现路径查询加速，且json_valid()返回0/1仅表语法有效。
MySQL 5.7 的 JSON 基础支持有限但可用
MySQL 5.7 在 5.7.8 版本起原生支持 JSON 类型，能存储、校验、解析 JSON 文本，并提供基础函数如 JSON_EXTRACT()、JSON_CONTAINS()、JSON_SET() 等。但它不支持对 JSON 字段的**部分更新（in-place update）**，每次修改都需全量重写整个 JSON 值；也没有针对 JSON 路径的**函数索引（functional index）**，只能对生成列建索引，且需显式定义 GENERATED COLUMN + STORED + 索引三步走。
常见错误现象：
– 执行 UPDATE t SET j = JSON_SET(j, '$.name', 'Alice') 会触发整行锁定和大字段重写，高并发下易成瓶颈；
– 尝试直接在 JSON_EXTRACT(j, '$.id') 上建索引会报错 ERROR 3105 (HY000): Expression of generated column ... cannot be used in index，除非先建生成列。
- 必须用
AS (JSON_EXTRACT(j, '$.id')) STORED显式声明生成列 - 生成列类型需匹配提取结果（如转为
UNSIGNED INT），否则索引不可用 -
JSON_VALID()在 5.7 中返回 0/1，但不会自动拦截非法 JSON 插入（除非字段设为JSON NOT NULL）
MySQL 8.0 新增 JSON_PARTIAL_UPDATE 和函数索引
MySQL 8.0.27 起支持真正的 JSON 部分更新，底层通过 JSON_PATCH() 或优化后的 JSON_SET()/JSON_REPLACE() 实现原子级字段级变更，避免整 JSON 重写。更重要的是，8.0 允许直接在表达式上建索引，比如：CREATE INDEX idx_user_id ON users ( (JSON_EXTRACT(profile, '$.user_id')) ) —— 括号里的表达式即“函数索引”语法，无需生成列中转。
使用场景：
– 用户资料表中 profile 是 JSON 字段，频繁按 $.user_id 查询，8.0 可一步建索引，5.7 必须多加一列再维护；
– 日志表中 event_data 存大量 JSON，需高频更新其中 $.status 字段，8.0 的部分更新可降低锁争用和 binlog 体积。
- 函数索引要求表达式确定性（deterministic），
JSON_EXTRACT()符合，但NOW()或RAND()不行 -
JSON_TABLE()是 8.0.4 新增函数，能把 JSON 数组展开为行集，配合函数索引可替代部分 ETL 场景 - 注意：函数索引仍受限于 InnoDB 单列索引长度上限（767 字节或 3072 字节，取决于
innodb_large_prefix）
JSON 聚合与路径操作函数差异明显
MySQL 5.7 完全没有 JSON 聚合能力，无法把多行 JSON 合并为一个数组或对象；而 8.0 引入了 JSON_ARRAYAGG() 和 JSON_OBJECTAGG()，可直接在 GROUP BY 中聚合结构化 JSON 数据。路径操作方面，5.7 的 JSON_CONTAINS_PATH() 只支持 'one' / 'all' 模式判断，8.0 新增 JSON_VALUE()（提取标量）、JSON_QUERY()（提取子文档）、JSON_OVERLAPS()（集合交集判断）等，语义更清晰、容错更强。
容易踩的坑：
– JSON_OBJECTAGG(key, value) 在 8.0 中 key 必须是字符串，若传入数字会隐式转为字符串，但 5.7 连这个函数都没有；
– JSON_EXTRACT() 返回带引号的字符串（如 "123"），而 JSON_VALUE() 默认去引号（返回 123），混用时类型比较可能出错；
– 5.7 中 JSON_UNQUOTE(JSON_EXTRACT(...)) 是取值标配，8.0 可用 JSON_VALUE() 替代，但要注意后者默认返回 CHAR(32768)，可能影响排序或连接性能。
字符集与默认行为变化影响 JSON 存储安全
MySQL 5.7 默认字符集是 latin1，JSON 字符串若含 emoji 或中文，插入时可能被截断或乱码；8.0 默认为 utf8mb4，天然兼容完整 Unicode。但这也带来一个隐蔽风险：5.7 中用 utf8（实际是 utf8mb3）建的表，升级到 8.0 后，JSON 字段若未显式指定 COLLATE utf8mb4_0900_as_cs，在大小写敏感比较（如 JSON_CONTAINS()）时行为可能不一致。
关键参数差异：
– json_valid() 在 5.7 返回 TINYINT，8.0 保持一致，但 8.0 对无效 UTF-8 字节更严格，可能拒绝插入；
– max_allowed_packet 影响 JSON 大对象读写，8.0 默认值未变，但因 JSON 函数链式调用更常见，实际更容易触达上限；
– 8.0 中 JSON_DEPTH()、JSON_LENGTH() 支持嵌套层级检测，5.7 无对应机制，深层 JSON 异常难定位。
真正复杂的地方在于：函数索引虽好，但 MySQL 不会自动为已有 JSON 字段补全索引；从 5.7 迁移过来的老表，即使升级到 8.0，也不会凭空获得 JSON_PARTIAL_UPDATE 或函数索引能力——必须手动重构表结构、重写查询逻辑，并验证所有 JSON 路径表达式在新版本下的执行计划是否真的走索引。
