mysql5.7以下怎么解析json

简单来说，该函数通过序列号和键名从 JSON 中获取值。
我上周刚刚处理了类似的请求。

测试数据是一个对象，而不是一个数组。
您提供的序列号 1 正确吗？只需使用键名即可直接搜索对象。

更改测试。
直接使用键名“old_grade_id”。

json函数在mysql中如何操作

糟糕，说到 MySQL 的 JSON 处理，我们必须从 5 .7 版本开始。
当时MySQL终于弄清楚了JSON数据类型，并创建了一组函数来方便我们操作这些JSON字段。
让我详细告诉你。

1 .首先，我们来谈谈插入/创建 JSON 数据。
我们必须使用两个函数 JSON_OBJECT 和 JSON_ARRAY。
例如，如果我们要向Users表中插入一条记录，并且该记录有一个信息字段，我们需要这样写：
sql INSERT INTO USERS (INFO) VALUES (JSON_OBJECT('姓名', '张三', '年龄', 2 5 , '爱好', JSON_ARRAY('读书', '游泳')));
这里，JSON_OBJECT 将键值对转换为 JSON 对象，JSON_ARRAY 将多个值转换为 JSON 数组。

2 要查询 JSON 字段，我们需要使用 JSON_EXTRACT。
例如要从Users表中查询张三的名字：
sql 从用户中选择 JSON_EXTRACT(info, '$.name'); -
返回：“张三”
还有一个运算符，与 JSON_EXTRACT 类似，但返回不带引号的文本值：
sql 从用户中按年龄选择信息 -> '$.age'; -
返回：2 5
注意，在路径表达式中，$代表根节点，点代表属性，方括号代表数组索引。

3 修改JSON数据，有几个函数：JSON_SET、JSON_INSERT、JSON_REPLACE和JSON_REMOVE。
比如要更新用户表中张三的年龄：
sql UPDATE USER SET INFO = JSON_SET(INFO, '$.age', 2 6 , '$.city', '北京');
这意味着如果age键存在，则更新其值，如果city键不存在，则更新它。
添加。

4 验证和判断JSON。
有几个函数：JSON_VALID、JSON_CONTAINS 和 JSON_OVERLAPS。
例如，如果你想检查一个字符串是否合法 JSON：
sql 选择 JSON_VALID('{ "name": "test" }'); -
返回：1 选择 JSON_VALID('invalidjson'); -
返回：0
它还具有JSON_CONTAINS，可以判断JSON中是否包含指定值：
sql 从用户中选择 JSON_CONTAINS(info, ''Beijing'', '$.city'); -
向北京城市的用户提问
5 、注意：路径表达式区分大小写，数组索引从0开始。
为了性能优化，可以考虑创建虚拟列并设置索引。
对于版本兼容性，注意MySQL版本是否足够。

所以，通过掌握这些函数，我们就可以在MySQL中高效地处理JSON数据了。
当时我无法理解这些细节，但现在使用起来非常简单。

为什么我的 MySQL 数据转换为 JSON 后斜杠变成了反斜杠？

记得上次在前端给同学发数据时，他显示的URL有一些正斜杠，这让我仔细检查了一下。
最后我发现这是我直接从数据库中提取的JSON字符串。
这个案子得从那天说起，具体来说是3 月1 5 日。
我在公司旧会议室的电脑屏幕前度过了很多时间。

MySQL中的字符串字段值原本是普通的http://example.com/path，但是到了PHP中，使用json_encode，就变成了http:\\example.com\\path。
这个现象很有趣。
其实不是PHP的问题，而是JSON编码规则的问题。
反斜杠是用来转义JSON中的特殊字符的，比如双引号"、反斜杠\本身以及反斜杠/。
你想想看，如果JSON字符串中直接有一个/，如果后面跟着一个>和script标签，岂不是很容易被用作XSS攻击的入口点？PHPslashesscape账户默认是json_encode安全。

我以为MySQL检测到的数据有问题，所以我尝试了SELECT JSON_QUOTE('url', 'http://example.com/path')) AS json_data;，结果完全正常，后来才知道是json_encode导致我之前看到的开源项目的JSON_UNESCAPED_SLASHES选项出现了问题，而且代码只有一行：
php $json = json_encode($data, JSON_UNESCAPED_SLASHES);
添加此选项后，生成的 JSON 字符串中的斜杠将保持不变。
这让我很惊讶。
没想到JSON编码器这么“小心”。
但仔细想想，事实确实如此。
毕竟现在很多前端框架都是直接解析JSON字符串的。
如果省略了斜线，可能需要重新处理，这是不必要的。
后来我尝试用正则表达式替换反斜杠，但发现效率低且容易出错，所以直接使用选项更方便。

但是过了一段时间我突然想到，如果数据量特别大，比如每条记录都有一个URL字段，是不是每个字段都要单独处理呢？这看起来有点麻烦。
也许更好的方法是查看前端是否可以接受带斜杠的 JSON，或者是否可以自动处理它。
你得问问你的同学，看看他是怎么处理的。
有时技术选择确实取决于具体情况。