mySQL中的JSON *** 作

创建单个json数组

创建单个对象，并返回该对象

将其他类型的值转换成JSON类型来获取json值

将 json 值作为参数传入，如果值有效，则返回其 json 类型，否则报错

将两个或多个 json 值合并为一个 json 并返回最终值

合并两个或多个 json 值，但不合并重复键的值，如果出现重复键，仅保留最后一个的值

经过函数转换得到的 json 是区分大小写的，原因在于转换后的字符集格式为 utf8mb4 和 utf8mb4_bin ,因为 utf8mb4_bin 是二进制排序规则，所以区分大小写

因为区分大小写，所以 json 中的 null 、 true 和 false 都必须用小写字母编写

直接插入键值对语句和用 JSON_OBJECT 转换成json值存入的差别在于，前者需要双反斜杠转义字符，而后者只需要单反斜杠转义字符

当需要存储的内容如下

使用直接插入的方法时：

使用 JSON_OBJECT 时

案例

因为 $[1] 和 $[2] 计算为非标量值, 所以它们可以用作选择嵌套值的更具体的路径表达式的基础。例子：

结合 JSON_SET``JSON_INSERT``JSON_REPLACE``JSON_REMOVE 的使用

JSON_SET 替换存在的路径的值, 并为不存在的路径添加值

JSON_INSERT 添加新值, 但不替换现有值:

JSON_REPLACE 替换现有值并忽略新值:

JSON_REMOVE 使用一个或多个路径, 这些路径指定要从文档中删除的值。返回值是原始文档减去由文档中存在的路径选择的值:

在MySQL与PostgreSQL的对比中，PG的JSON格式支持优势总是不断被拿来比较。其实早先MariaDB也有对非结构化的数据进行存储的方案，称为dynamic column，但是方案是通过BLOB类型的方式来存储。这样导致的问题是查询性能不高，不能有效建立索引，与一些文档数据库对比，优势并不大，故在社区的反应其实比较一般。当然，MariaDB的dynamic column功能还不仅限于非结构化数据的存储，但不在本文进行展开。

MySQL 5.7.7 labs版本开始InnoDB存储引擎已经原生支持JSON格式，该格式不是简单的BLOB类似的替换。原生的JSON格式支持有以下的优势：

JSON数据有效性检查：BLOB类型无法在数据库层做这样的约束性检查

查询性能的提升：查询不需要遍历所有字符串才能找到数据

支持索引：通过虚拟列的功能可以对JSON中的部分数据进行索引

首先我们来看如何在MySQL中使用原生的JSON格式：

mysql>create table user ( uid int auto_increment,

->data json,primary key(uid))engine=innodb

Query OK, 0 rows affected (0.01 sec)

mysql>insert into user values (NULL,

->'{"name":"David","mail":"jiangchengyao@gmail.com","address":"Shangahai"}')

Query OK, 1 row affected (0.00 sec)

mysql>insert into user values (NULL,'{"name":"Amy","mail":"amy@gmail.com"}')

Query OK, 1 row affected (0.00 sec)

可以看到我们新建了表user，并且将列data定义为了JSON类型。这意味着我们可以对插入的数据做JSON格式检查，确保其符合JSON格式的约束，如插入一条不合法的JSON数据会报如下错误：

mysql>insert into user values (NULL,"test")

ERROR 3130 (22032): Invalid JSON text: "Invalid value" at position 2 in value (or column) 'test'.

此外，正如前面所说的，MySQL 5.7提供了一系列函数来高效地处理JSON字符，而不是需要遍历所有字符来查找，这不得不说是对MariaDB dynamic column的巨大改进：

mysql>select jsn_extract(data, '$.name'),jsn_extract(data,'$.address') from user

+-----------------------------+-------------------------------+

| jsn_extract(data, '$.name') | jsn_extract(data,'$.address') |

+-----------------------------+-------------------------------+

| "David" | "Shangahai" |

| "Amy" | NULL |

+-----------------------------+-------------------------------+

2 rows in set (0.00 sec)

当然，最令人的激动的功能应该是MySQL 5.7的虚拟列功能，通过传统的B+树索引即可实现对JSON格式部分属性的快速查询。使用方法是首先创建该虚拟列，然后在该虚拟列上创建索引：

mysql>ALTER TABLE user ADD user_name varchar(128)

->GENERATED ALWAYS AS (jsn_extract(data,'$.name')) VIRTUAL

Query OK, 0 rows affected (0.01 sec)

Records: 0 Duplicates: 0 Warnings: 0

mysql>select user_name from user

+-----------+

| user_name |

+-----------+

| "Amy" |

| "David" |

+-----------+

2 rows in set (0.00 sec)

mysql>alter table user add index idx_username (user_name)

Query OK, 2 rows affected (0.01 sec)

Records: 2 Duplicates: 0 Warnings: 0

然后可以通过添加的索引对用户名进行快速的查询，这和普通类型的列查询一样。而通过explain可以验证优化器已经选择了在虚拟列上创建的新索引：

mysql>explain select * from user where user_name='"Amy"'\G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: user

partitions: NULL

type: ref

possible_keys: idx_username

key: idx_username

key_len: 131

ref: const

rows: 1

filtered: 100.00

Extra: NULL

1 row in set, 1 warning (0.00 sec)

可以发现MySQL 5.7对于JSON格式堪称完美，相信PostgreSQL阵营需要寻找新的策略来“攻击”MySQL了吧。如无意外，还是会停留在优化器这块，毕竟这块是目前MySQL必须要克服的最大问题，好在MySQL团队已经在重构优化器代码，相信更好的优化器将会在下一个版本中全面爆发。而一大堆文档数据库们已经哭晕在厕所了吧。

---