关系型的结构化存储存在一定的弊端,因为它需要预先定义好所有的列以及列对应的类型。但是业务在发展过程中,或许需要扩展单个列的描述功能,这时,如果能用好 JSON 数据类型,那就能打通关系型和非关系型数据的存储之间的界限,为业务提供更好的架构选择。
当然,很多同学在用 JSON 数据类型时会遇到各种各样的问题,其中最容易犯的误区就是将类型 JSON 简单理解成字符串类型 。真正认识到 JSON 数据类型的威力,从而在实际工作中更好地存储非结构化的数据。

JSON 数据类型

JSON(JavaScript Object Notation)主要用于互联网应用服务之间的数据交换。MySQL 支持RFC 7159定义的 JSON 规范,主要有 JSON 对象JSON 数组 两种类型。下面就是 JSON 对象,主要用来存储图片的相关信息:

  1. {
  2. "Image": {
  3. "Width": 800,
  4. "Height": 600,
  5. "Title": "View from 15th Floor",
  6. "Thumbnail": {
  7. "Url": "http://www.example.com/image/481989943",
  8. "Height": 125,
  9. "Width": 100
  10. },
  11. "IDs": [116, 943, 234, 38793]
  12. }
  13. }

从中可以看到, JSON 类型可以很好地描述数据的相关内容,比如这张图片的宽度、高度、标题等(这里使用到的类型有整型、字符串类型)。
JSON对象除了支持字符串、整型、日期类型,JSON 内嵌的字段也支持数组类型,如上代码中的 IDs 字段。
另一种 JSON 数据类型是数组类型,如:

  1. [
  2. {
  3. "precision": "zip",
  4. "Latitude": 37.7668,
  5. "Longitude": -122.3959,
  6. "Address": "",
  7. "City": "SAN FRANCISCO",
  8. "State": "CA",
  9. "Zip": "94107",
  10. "Country": "US"
  11. },
  12. {
  13. "precision": "zip",
  14. "Latitude": 37.371991,
  15. "Longitude": -122.026020,
  16. "Address": "",
  17. "City": "SUNNYVALE",
  18. "State": "CA",
  19. "Zip": "94085",
  20. "Country": "US"
  21. }
  22. ]

上面的示例演示的是一个 JSON 数组,其中有 2 个 JSON 对象。
到目前为止,可能很多同学会把 JSON 当作一个很大的字段串类型,从表面上来看,没有错。但本质上,JSON 是一种新的类型,有自己的存储格式,还能在每个对应的字段上创建索引,做特定的优化,这是传统字段串无法实现的。JSON 类型的另一个好处是无须预定义字段 ,字段可以无限扩展。而传统关系型数据库的列都需预先定义,想要扩展需要执行 ALTER TABLE … ADD COLUMN … 这样比较重的操作。
需要注意是,JSON 类型是从 MySQL 5.7 版本开始支持的功能,而 8.0 版本解决了更新 JSON 的日志性能瓶颈。如果要在生产环境中使用 JSON 数据类型,强烈推荐使用 MySQL 8.0 版本。
已经对 JSON 类型的基本概念有所了解了,接下来进入实战环节:如何在业务中用好JSON类型?

业务表结构设计实战

用户登录设计

在数据库中,JSON 类型比较适合存储一些修改较少、相对静态的数据 ,比如用户登录信息的存储如下:

  1. DROP TABLE IF EXISTS UserLogin;
  2. CREATE TABLE UserLogin (
  3. userId BIGINT NOT NULL,
  4. loginInfo JSON,
  5. PRIMARY KEY(userId)
  6. );

由于当前业务的登录方式越来越多样化,如同一账户支持手机、微信、QQ 账号登录,所以这里可以用 JSON 类型存储登录的信息。
接着,插入下面的数据:

  1. SET @a = '
  2. {
  3. "cellphone" : "13918888888",
  4. "wxchat" : "破产码农",
  5. "QQ" : "82946772"
  6. }
  7. ';
  8. INSERT INTO UserLogin VALUES (1,@a);
  9. SET @b = '
  10. {
  11. "cellphone" : "15026888888"
  12. }
  13. ';
  14. INSERT INTO UserLogin VALUES (2,@b);

从上面的例子中可以看到,用户 1 登录有三种方式:手机验证码登录、微信登录、QQ 登录,而用户 2 只有手机验证码登录。
而如果不采用 JSON 数据类型,就要用下面的方式建表:

  1. SELECT
  2. userId,
  3. JSON_UNQUOTE(JSON_EXTRACT(loginInfo,"$.cellphone")) cellphone,
  4. JSON_UNQUOTE(JSON_EXTRACT(loginInfo,"$.wxchat")) wxchat
  5. FROM UserLogin;
  6. +--------+-------------+--------------+
  7. | userId | cellphone | wxchat |
  8. +--------+-------------+--------------+
  9. | 1 | 13918888888 | 破产码农 |
  10. | 2 | 15026888888 | NULL |
  11. +--------+-------------+--------------+
  12. 2 rows in set (0.01 sec)

当然了,每次写 JSON_EXTRACTJSON_UNQUOTE 非常麻烦,MySQL 还提供了 ->> 表达式,和上述 SQL 效果完全一样:

  1. SELECT
  2. userId,
  3. loginInfo->>"$.cellphone" cellphone,
  4. loginInfo->>"$.wxchat" wxchat
  5. FROM UserLogin;

当 JSON 数据量非常大,用户希望对 JSON 数据进行有效检索时,可以利用 MySQL 的 函数索引 功能对 JSON 中的某个字段进行索引。
比如在上面的用户登录示例中,假设用户必须绑定唯一手机号,且希望未来能用手机号码进行用户检索时,可以创建下面的索引:

  1. ALTER TABLE UserLogin ADD COLUMN cellphone VARCHAR(255) AS (loginInfo->>"$.cellphone");
  2. ALTER TABLE UserLogin ADD UNIQUE INDEX idx_cellphone(cellphone);

上述 SQL 首先创建了一个虚拟列 cellphone,这个列是由函数 loginInfo->>"$.cellphone" 计算得到的。然后在这个虚拟列上创建一个唯一索引 idx_cellphone。这时再通过虚拟列 cellphone 进行查询,就可以看到优化器会使用到新创建的 idx_cellphone 索引:

  1. EXPLAIN SELECT * FROM UserLogin
  2. WHERE cellphone = '13918888888'\G
  3. *************************** 1. row ***************************
  4. id: 1
  5. select_type: SIMPLE
  6. table: UserLogin
  7. partitions: NULL
  8. type: const
  9. possible_keys: idx_cellphone
  10. key: idx_cellphone
  11. key_len: 1023
  12. ref: const
  13. rows: 1
  14. filtered: 100.00
  15. Extra: NULL
  16. 1 row in set, 1 warning (0.00 sec)

当然,可以在一开始创建表的时候,就完成虚拟列及函数索引的创建。如下表创建的列 cellphone 对应的就是 JSON 中的内容,是个虚拟列;uk_idx_cellphone 就是在虚拟列 cellphone 上所创建的索引。

  1. CREATE TABLE UserLogin (
  2. userId BIGINT,
  3. loginInfo JSON,
  4. cellphone VARCHAR(255) AS (loginInfo->>"$.cellphone"),
  5. PRIMARY KEY(userId),
  6. UNIQUE KEY uk_idx_cellphone(cellphone)
  7. );

用户画像设计

某些业务需要做用户画像(也就是对用户打标签),然后根据用户的标签,通过数据挖掘技术,进行相应的产品推荐。比如:

  • 在电商行业中,根据用户的穿搭喜好,推荐相应的商品;
  • 在音乐行业中,根据用户喜欢的音乐风格和常听的歌手,推荐相应的歌曲;
  • 在金融行业,根据用户的风险喜好和投资经验,推荐相应的理财产品。

在这,强烈推荐用 JSON 类型在数据库中存储用户画像信息,并结合 JSON 数组类型和多值索引的特点进行高效查询。假设有张画像定义表:

  1. CREATE TABLE Tags (
  2. tagId bigint auto_increment,
  3. tagName varchar(255) NOT NULL,
  4. primary key(tagId)
  5. );
  6. SELECT * FROM Tags;
  7. +-------+--------------+
  8. | tagId | tagName |
  9. +-------+--------------+
  10. | 1 | 70 |
  11. | 2 | 80 |
  12. | 3 | 90 |
  13. | 4 | 00 |
  14. | 5 | 爱运动 |
  15. | 6 | 高学历 |
  16. | 7 | 小资 |
  17. | 8 | 有房 |
  18. | 9 | 有车 |
  19. | 10 | 常看电影 |
  20. | 11 | 爱网购 |
  21. | 12 | 爱外卖 |
  22. +-------+--------------+

可以看到,表 Tags 是一张画像定义表,用于描述当前定义有多少个标签,接着给每个用户打标签,比如用户 David,他的标签是 80 后、高学历、小资、有房、常看电影;用户 Tom,90 后、常看电影、爱外卖。
若不用 JSON 数据类型进行标签存储,通常会将用户标签通过字符串,加上分割符的方式,在一个字段中存取用户所有的标签:

  1. +-------+---------------------------------------+
  2. |用户 |标签 |
  3. +-------+---------------------------------------+
  4. |David |80 高学历 小资 有房 ;常看电影 |
  5. |Tom |90 ;常看电影 爱外卖 |
  6. +-------+----------------------------------------

这样做的缺点是 :不好搜索特定画像的用户,另外分隔符也是一种自我约定,在数据库中其实可以任意存储其他数据,最终产生脏数据。
用 JSON 数据类型就能很好解决这个问题:

  1. DROP TABLE IF EXISTS UserTag;
  2. CREATE TABLE UserTag (
  3. userId bigint NOT NULL,
  4. userTags JSON,
  5. PRIMARY KEY (userId)
  6. );
  7. INSERT INTO UserTag VALUES (1,'[2,6,8,10]');
  8. INSERT INTO UserTag VALUES (2,'[3,10,12]');

其中,userTags 存储的标签就是表 Tags 已定义的那些标签值,只是使用 JSON 数组类型进行存储。
MySQL 8.0.17 版本开始支持 Multi-Valued Indexes,用于在 JSON 数组上创建索引,并通过函数 member ofjson_containsjson_overlaps 来快速检索索引数据。所以可以在表 UserTag 上创建 Multi-Valued Indexes:

  1. ALTER TABLE UserTag
  2. ADD INDEX idx_user_tags ((cast((userTags->"$") as unsigned array)));

如果想要查询用户画像为常看电影的用户,可以使用函数 MEMBER OF:

  1. EXPLAIN SELECT * FROM UserTag
  2. WHERE 10 MEMBER OF(userTags->"$")\G
  3. *************************** 1. row ***************************
  4. id: 1
  5. select_type: SIMPLE
  6. table: UserTag
  7. partitions: NULL
  8. type: ref
  9. possible_keys: idx_user_tags
  10. key: idx_user_tags
  11. key_len: 9
  12. ref: const
  13. rows: 1
  14. filtered: 100.00
  15. Extra: Using where
  16. 1 row in set, 1 warning (0.00 sec)
  17. SELECT * FROM UserTag
  18. WHERE 10 MEMBER OF(userTags->"$");
  19. +--------+---------------+
  20. | userId | userTags |
  21. +--------+---------------+
  22. | 1 | [2, 6, 8, 10] |
  23. | 2 | [3, 10, 12] |
  24. +--------+---------------+
  25. 2 rows in set (0.00 sec)

如果想要查询画像为 80 后,且常看电影的用户,可以使用函数 JSON_CONTAINS:

  1. EXPLAIN SELECT * FROM UserTag
  2. WHERE JSON_CONTAINS(userTags->"$", '[2,10]')\G
  3. *************************** 1. row ***************************
  4. id: 1
  5. select_type: SIMPLE
  6. table: UserTag
  7. partitions: NULL
  8. type: range
  9. possible_keys: idx_user_tags
  10. key: idx_user_tags
  11. key_len: 9
  12. ref: NULL
  13. rows: 3
  14. filtered: 100.00
  15. Extra: Using where
  16. 1 row in set, 1 warning (0.00 sec)
  17. SELECT * FROM UserTag
  18. WHERE JSON_CONTAINS(userTags->"$", '[2,10]');
  19. +--------+---------------+
  20. | userId | userTags |
  21. +--------+---------------+
  22. | 1 | [2, 6, 8, 10] |
  23. +--------+---------------+
  24. 1 row in set (0.00 sec)

如果想要查询画像为 80 后、90 后,且常看电影的用户,则可以使用函数 JSON_OVERLAP:

  1. EXPLAIN SELECT * FROM UserTag
  2. WHERE JSON_OVERLAPS(userTags->"$", '[2,3,10]')\G
  3. *************************** 1. row ***************************
  4. id: 1
  5. select_type: SIMPLE
  6. table: UserTag
  7. partitions: NULL
  8. type: range
  9. possible_keys: idx_user_tags
  10. key: idx_user_tags
  11. key_len: 9
  12. ref: NULL
  13. rows: 4
  14. filtered: 100.00
  15. Extra: Using where
  16. 1 row in set, 1 warning (0.00 sec)
  17. SELECT * FROM UserTag
  18. WHERE JSON_OVERLAPS(userTags->"$", '[2,3,10]');
  19. +--------+---------------+
  20. | userId | userTags |
  21. +--------+---------------+
  22. | 1 | [2, 6, 8, 10] |
  23. | 2 | [3, 10, 12] |
  24. +--------+---------------+
  25. 2 rows in set (0.01 sec)

总结

JSON 类型是 MySQL 5.7 版本新增的数据类型,用好 JSON 数据类型可以有效解决很多业务中实际问题。最后,总结下今天的重点内容:

  • 使用 JSON 数据类型,推荐用 MySQL 8.0.17 以上的版本,性能更好,同时也支持 Multi-Valued Indexes;
  • JSON 数据类型的好处是无须预先定义列,数据本身就具有很好的描述性;
  • 不要将有明显关系型的数据用 JSON 存储,如用户余额、用户姓名、用户身份证等,这些都是每个用户必须包含的数据;
  • JSON 数据类型推荐使用在不经常更新的静态数据存储。