Question

mysql怎么搜索json格式的数据

Answer 1

在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团队已经在重构优化器代码，相信更好的优化器将会在下一个版本中全面爆发。而一大堆文档数据库们已经哭晕在厕所了吧。

Answer 2

我们知道，JSON是一种轻量级的数据交互的格式，大部分NO SQL数据库的存储都用JSON。MySQL从5.7开始支持JSON格式的数据存储，并且新增了很多JSON相关函数。MySQL 8.0 又带来了一个新的把JSON转换为TABLE的函数JSON_TABLE，实现了JSON到表的转换。

举例一

我们看下简单的例子：

简单定义一个两级JSON 对象

mysql> set @ytt='{"name":[{"a":"ytt","b":"action"},  {"a":"dble","b":"shard"},{"a":"mysql","b":"oracle"}]}';Query OK, 0 rows affected (0.00 sec)

第一级：

mysql> select json_keys(@ytt);+-----------------+| json_keys(@ytt) |+-----------------+| ["name"]        |+-----------------+1 row in set (0.00 sec)

第二级：

mysql> select json_keys(@ytt,'$.name[0]');+-----------------------------+| json_keys(@ytt,'$.name[0]') |+-----------------------------+| ["a", "b"]                  |+-----------------------------+1 row in set (0.00 sec)

我们使用MySQL 8.0 的JSON_TABLE 来转换 @ytt。

• mysql> select * from json_table(@ytt,'$.name[*]' columns (f1 varchar(10) path '$.a', f2 varchar(10) path '$.b')) as tt;

• +-------+--------+

• | f1    | f2     |

• +-------+--------+

• | ytt   | action |

• | dble  | shard  |

• | mysql | oracle |

• +-------+--------+

• 3 rows in set (0.00 sec)

举例二

再来一个复杂点的例子，用的是EXPLAIN 的JSON结果集。

JSON 串 @json_str1。

• set @json_str1 = ' {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "1.00"    },    "table": {      "table_name": "bigtable",      "access_type": "const",      "possible_keys": [        "id"      ],      "key": "id",      "used_key_parts": [        "id"      ],      "key_length": "8",      "ref": [        "const"      ],      "rows_examined_per_scan": 1,      "rows_produced_per_join": 1,      "filtered": "100.00",      "cost_info": {        "read_cost": "0.00",        "eval_cost": "0.20",        "prefix_cost": "0.00",        "data_read_per_join": "176"      },      "used_columns": [        "id",        "log_time",        "str1",        "str2"      ]    }  }}';




第一级：

• mysql> select json_keys(@json_str1) as 'first_object';+-----------------+| first_object    |+-----------------+| ["query_block"] |+-----------------+1 row in set (0.00 sec)




第二级：

• mysql> select json_keys(@json_str1,'$.query_block') as 'second_object';+-------------------------------------+| second_object                       |+-------------------------------------+| ["table", "cost_info", "select_id"] |+-------------------------------------+1 row in set (0.00 sec)




第三级：

• mysql>  select json_keys(@json_str1,'$.query_block.table') as 'third_object'\G*************************** 1. row ***************************third_object: ["key","ref","filtered","cost_info","key_length","table_name","access_type","used_columns","possible_keys","used_key_parts","rows_examined_per_scan","rows_produced_per_join"]1 row in set (0.01 sec)




第四级：

• mysql> select json_extract(@json_str1,'$.query_block.table.cost_info') as 'forth_object'\G*************************** 1. row ***************************forth_object: {"eval_cost":"0.20","read_cost":"0.00","prefix_cost":"0.00","data_read_per_join":"176"}1 row in set (0.00 sec)




那我们把这个JSON 串转换为表。

• SELECT * FROM JSON_TABLE(@json_str1,

• "$.query_block"

• COLUMNS(

• rowid FOR ORDINALITY,

• NESTED PATH '$.table'

• COLUMNS (

• a1_1 varchar(100) PATH '$.key',

• a1_2 varchar(100) PATH '$.ref[0]',

• a1_3 varchar(100) PATH '$.filtered',

• nested path '$.cost_info'

• columns (

• a2_1 varchar(100) PATH '$.eval_cost' ,

• a2_2 varchar(100) PATH '$.read_cost',

• a2_3 varchar(100) PATH '$.prefix_cost',

• a2_4 varchar(100) PATH '$.data_read_per_join'

• ),

• a3 varchar(100) PATH '$.key_length',

• a4 varchar(100) PATH '$.table_name',

• a5 varchar(100) PATH '$.access_type',

• a6 varchar(100) PATH '$.used_key_parts[0]',

• a7 varchar(100) PATH '$.rows_examined_per_scan',

• a8 varchar(100) PATH '$.rows_produced_per_join',

• a9 varchar(100) PATH '$.key'

• ),

• NESTED PATH '$.cost_info'

• columns (

• b1_1 varchar(100) path '$.query_cost'

• ),

• c INT path "$.select_id"

• )

• ) AS tt;

• +-------+------+-------+--------+------+------+------+------+------+----------+-------+------+------+------+------+------+------+

• | rowid | a1_1 | a1_2  | a1_3   | a2_1 | a2_2 | a2_3 | a2_4 | a3   | a4       | a5    | a6   | a7   | a8   | a9   | b1_1 | c    |

• +-------+------+-------+--------+------+------+------+------+------+----------+-------+------+------+------+------+------+------+

• |     1 | id   | const | 100.00 | 0.20 | 0.00 | 0.00 | 176  | 8    | bigtable | const | id   | 1    | 1    | id   | NULL |    1 |

• |     1 | NULL | NULL  | NULL   | NULL | NULL | NULL | NULL | NULL | NULL     | NULL  | NULL | NULL | NULL | NULL | 1.00 |    1 |

• +-------+------+-------+--------+------+------+------+------+------+----------+-------+------+------+------+------+------+------+

• 2 rows in set (0.00 sec)

当然，JSON_table 函数还有其他的用法，我这里不一一列举了，详细的参考手册。



请点击输入图片描述

请点击输入图片描述

修改回答