腾讯云数据库团队：MySQL5.7 JSON实现简介

做者介绍：吴双桥 腾讯云工程师

阅读原文，更多技术干货，请访问腾云阁。

本文主要介绍在MySQL 5.7.7开始引入的非结构化数据类型JSON的特性以及具体的实现方式(包括存储方式)。首先介绍为何要引入JSON的原生数据类型的支持；接着介绍MySQL给用户提供的JSON操做函数，以及JSON路径表达式语法，结合二者，用户能够在数据库级别操做JSON的任意键值和数据；以后，重点介绍JSON在服务器侧的存储结构，这也是深刻理解不少其余JSON特性的根基；在最后介绍JSON做为新数据类型的比较与排序规则以前，介绍了对JSON类型数据创建索引的原理。

为何JSON的原生支持

1. 文档合法性

在MySQL5.7.7对JSON提供原生类型的支持以前，用户能够用TEXT或者BLOB类型来存储JSON文档。但对于MySQL来讲，用户插入的数据只是序列化后的一个普通的字符串，不会对JSON文档自己的语法合法性作检查，文档的合法性须要用户本身保证。在引入新的JSON类型以后，插入语法错误的JSON文档，MySQL会提示错误，并在插入以后作归一化处理，保证每个键对应一个值。

1. 更有效的访问

MySQL 5.7.7+自己提供了不少原生的函数以及路径表达式来方便用户访问JSON数据。例如对于下面的JSON文档： { "a": [ [ 3, 2 ], [ { "c" : "d" }, 1 ] ], "b": { "c" : 6 }, "one potato": 7, "b.c" : 8 }

用户可使用 $.a[1][0]获取{ "c" : "d" }， $.a[1]获取[ { "c" : "d" }, 1 ] 还可使用通配符 * 和 ** 来进行模糊匹配，详见下一段。

1. 性能优化

在MySQL提供JSON原生支持以前，若是用户须要获取或者修改某个JSON文档的键值，须要把TEXT或者BLOB整个字符串读出来反序列化成JSON对象，而后经过各类库函数访问JSON数据。显然这样是很是没有效率的，特别是对较大的文档。而原生JSON的性能，特别是读性能很是好。根据Oracle公司针对200K+数据文档作的性能测试代表，一样的数据用TEXT和JSON类型的查询性能差别达到两个数量级以上，并且用户还能够对常常访问的JSON键值作索引，进一步提高性能。JSON数据操做性能的提高是基于JSON数据自己的存储结构的，下文会进一步介绍。

JSON的操做接口及路径表达式

1. JSON的操做接口 根据MySQL官方文档的介绍，服务器端JSON函数的实现须要知足如下条件：

Requirements:

1. Lets users construct JSON data values from other relational data.

2. Lets users extract relational data from JSON data values.

3. Lets users minimally introspect the structure of JSON values and text (validity, length, depth, keys).

4. Works on strings which are utf8mb4 encoded.

5. Performance should be suitable for read-intensive applications.

Non-requirements:

1. May produce surprising results on strings which are not utf8mb4 encoded.

2. There is limited support for decimal values nested inside JSON documents.

3. Performance may not be suitable for write-intensive applications.

提供的函数列表具体为：

JSON_APPEND() JSON_ARRAY_INSERT() JSON_UNQUOTE() JSON_ARRAY()
 JSON_REPLACE() JSON_CONTAINS() JSON_DEPTH() JSON_EXTRACT()
JSON_INSERT() JSON_KEYS() JSON_LENGTH() JSON_VALID()
JSON_MERGE() JSON_OBJECT() JSON_QUOTE() JSON_REMOVE()
JSON_CONTAINS_PATH() JSON_SEARCH() JSON_SET() JSON_TYPE()

以上函数的调用规则大多形如：

JSON_APPEND(json_doc, path, val[, path, val] ...)

第一个参数`json_doc`为JSON文档，或者是表里面的某一列，也能够是JSON文档里面的嵌套子文档变量；
第二个参数`path`为路径表达式，用来定位要访问的键，`path`(即路径表达式)下面紧接着会介绍；
第三个参数`val`有的函数可能没有，如有表示键对应的操做数值。

1. JSON路径表达式 为了更方便快速的访问JSON的键值，MySQL 5.7.7+提供了新的路径表达式语法支持。前文提到的$.a[1][0]就是路径表达式的一个具体的示例。完整的路径表达式语法为：

pathExpression> ::= scope  [ ( pathLeg )* ]
scope ::= [ columnReference ] dollarSign
columnReference ::= [ [ databaseIdentifier period  ] tableIdentifier period ] columnIdentifier
databaseIdentifier ::= sqlIdentifier
tableIdentifier ::= sqlIdentifier
columnIdentifier ::= sqlIdentifier
pathLeg ::= member | arrayLocation | doubleAsterisk
member ::= period ( keyName | asterisk )
arrayLocation ::= leftBracket ( non-negative-integer | asterisk ) rightBracket
 keyName ::= ECMAScript-identifier | double-quoted-string-literal
doubleAsterisk ::= **

仍是以

{ "a": [ [ 3, 2 ], [ { "c" : "d" }, 1 ] ], "b": { "c" : 6 }, "one potato": 7, "b.c" : 8 }

为例，再举几个例子说明：

$.a[1] 获取的值为 [ { "c" : "d" }, 1 ] $.b.c 获取的值为 6 $."b.c" 获取的值为 8

对比上面最后两个例子，能够看到用引号包围的表达式会被看成一个字符串键值。

关于通配符*和**来进行模糊匹配须要作进一步的说明。

两个连着星号**不能做为表达式的结尾，不能出现连续的三个星号*** 单个星号*表示匹配某个JSON对象中全部的成员 [*]表示匹配某个JSON数组中的全部元素 prefix**suffix表示全部以prefix开始，以suffix结尾的路径

举个具体的例子，直接在MySQL命令行里面输入：

获得显示结果：["d", 6]。

JSON的存储结构及具体实现

在处理JSON时，MySQL使用的utf8mb4字符集，utf8mb4是utf8和ascii的超集。因为历史缘由，这里utf8并不是是咱们常说的UTF-8 Unicode变长编码方案，而是MySQL自身定义的utf8编码方案，最长为三个字节。具体区别非本文重点，请你们自行Google了解。

MySQL在内存中是以DOM的形式表示JSON文档，并且在MySQL解析某个具体的路径表达式时，只须要反序列化和解析路径上的对象，并且速度极快。要弄清楚MySQL是如何作到这些的，咱们就须要了解JSON在硬盘上的存储结构。有个有趣的点是，JSON对象是BLOB的子类，在其基础上作了特化。

根据MySQL官方文档的表述：

On a high level, we will store the contents of the JSON document in three sections:

• A table of pointers to all the keys and values, in the order in which the keys and values are stored. Each pointer contains information about where the data associated with the key or the value is located, as well as type information about the key or value pointed to.

*All the keys. The keys are sorted, so that lookup can use binary search to locate the key quickly.

• All the values, in the same order as their corresponding keys. If the document is an array, it has two sections only: the dictionary and the values. If the document is a scalar, it has a single section which contains the scalar value

咱们来使用示意图更清晰的展现它的结构： JSON文档自己是层次化的结构，于是MySQL对JSON存储也是层次化的。对于每一级对象，存储的最前面为存放当前对象的元素个数，以及总体占的大小。须要注意的是：

• JSON对象的Key索引（图中橙色部分）都是排序好的，先按长度排序，长度相同的按照code point排序；Value索引（图中黄色部分）根据对应的Key的位置依次排列，最后面真实的数据存储（图中白色部分）也是如此

• Key和Value的索引对存储了对象内的偏移和大小，单个索引的大小固定，能够经过简单的算术跳转到距离为N的索引

• 经过MySQL5.7.16源代码能够看到，在序列化JSON文档时，MySQL会动态检测单个对象的大小，若是小于64KB使用两个字节的偏移量，不然使用四个字节的偏移量，以节省空间。同时，动态检查单个对象是不是大对象，会形成对大对象进行两次解析，源代码中也指出这是之后须要优化的点

• 如今受索引中偏移量和存储大小四个字节大小的限制，单个JSON文档的大小不能超过4G；单个KEY的大小不能超过两个字节，即64K

• 索引存储对象内的偏移是为了方便移动，若是某个键值被改动，只用修改受影响对象总体的偏移量

• 索引的大小如今是冗余信息，由于经过相邻偏移能够简单的获得存储大小，主要是为了应对变长JSON对象值更新，若是长度变小，JSON文档总体都不用移动，只须要当前对象修改大小

• 如今MySQL对于变长大小的值没有预留额外的空间，也就是说若是该值的长度变大，后面的存储都要受到影响

• 结合JSON的路径表达式能够知道，JSON的搜索操做只用反序列化路径上涉及到的元素，速度很是快，实现了读操做的高性能

• 不过，MySQL对于大型文档的变长键值的更新操做可能会变慢，可能并不适合写密集的需求

JSON的索引

如今MySQL不支持对JSON列进行索引，官网文档的说明是：

JSON columns cannot be indexed. You can work around this restriction by creating an index on a generated column that extracts a scalar value from the JSON column.

虽然不支持直接在JSON列上建索引，但MySQL规定，能够首先使用路径表达式对JSON文档中的标量值创建虚拟列，而后在虚拟列上创建索引。这样用户可使用表达式对本身感兴趣的键值创建索引。举个具体的例子来讲明：

CREATE TABLE features (
 id INT NOT NULL AUTO_INCREMENT,
 feature JSON NOT NULL,
 PRIMARY KEY (id)
);

插入它的JSON数据的格式为：

{
   "type":"Feature",
   "properties":{
      "TO_ST":"0",
      "BLKLOT":"0001001",
      "STREET":"UNKNOWN",
      "FROM_ST":"0",
      "LOT_NUM":"001",
      "ST_TYPE":null,
      "ODD_EVEN":"E",
      "BLOCK_NUM":"0001",
      "MAPBLKLOT":"0001001"
   }
}

使用：

ALTER TABLE features ADD feature_street VARCHAR(30) AS (JSON_UNQUOTE(feature->"$.properties.STREET"));
ALTER TABLE features ADD INDEX (feature_street);

两个步骤，能够对feature列中properties键值下的STREET键(feature->"$.properties.STREET")建立索引。

其中，feature_street列就是新添加的虚拟列。之因此取名虚拟列，是由于与它对应的还有一个存储列(stored column)。它们最大的区别为虚拟列只修改数据库的metadata，并不会存储真实的数据在硬盘上，读取过程也是实时计算的方式；而存储列会把表达式的列存储在硬盘上。二者使用的场景不同，默认状况下经过表达式生成的列为虚拟列。

这样虚拟列的添加和删除都会很是快，而在虚拟列上创建索引跟传统的创建索引的方式并无区别，会提升虚拟列读取的性能，减慢总体插入的性能。虚拟列的特性结合JSON的路径表达式，能够方便的为用户提供高效的键值索引功能。

JSON比较与排序

JSON值可使用=, <, <=, >, >=, <>, !=, <=>等操做符，BETWEEN, IN,GREATEST, LEAST等操做符如今还不支持。JSON值使用的两级排序规则，第一级基于JSON的类型，类型不一样的使用每一个类型特有的排序规则。

JSON类型按照优先级从高到低为

BLOB
BIT
OPAQUE
DATETIME
TIME
DATE
BOOLEAN
ARRAY
OBJECT
STRING
INTEGER, DOUBLE
NULL

优先级高的类型大，不用再进行其余的比较操做；若是类型相同，每一个类型按本身的规则排序。具体的规则以下：

1. BLOB/BIT/OPAQUE: 比较两个值前N个字节，若是前N个字节相同，短的值小

2. DATETIME/TIME/DATE: 按照所表示的时间点排序

3. BOOLEAN: false小于true

4. ARRAY: 两个数组若是长度和在每一个位置的值相同时相等，若是不想等，取第一个不相同元素的排序结果，空元素最小

5. OBJECT: 若是两个对象有相同的KEY，而且KEY对应的VALUE也都相同，二者相等。不然，二者大小不等，但相对大小未规定。

6. STRING: 取两个STRING较短的那个长度为N，比较两个值utf8mb4编码的前N个字节，较短的小，空值最小

7. INTEGER/DOUBLE: 包括精确值和近似值的比较，稍微有点复杂，可能出现与直觉相悖的结果，具体参见[官方文档](http://dev.mysql.com/doc/refman/5.7/en/json.html#json-comparison)相关说明。

任何JSON值与SQL的NULL常量比较，获得的结果是UNKNOWN。对于JSON值和非JSON值的比较，按照必定的规则将非JSON值转化为JSON值，而后按照以上的规则进行比较。

小结

本文主要介绍了MySQL在5.7.7以后引入的原生JSON支持的特性，说明了引入JSON类型的好处，并结合具体的示例介绍了MySQL在JSON类型上对外的接口以及引入的新语法规则。此外，还重点介绍了JSON在硬盘上的存储结构，简要分析了这种存储结构的优点和不足。最后还介绍了JSON的索引原理，以及比较和排序规则。相信理解了本文介绍的内容，关于JSON文中没有提到的部份内容也较容易理解。

相关推荐

MySQL内核深度优化

MySQL数据库的高可用性分析

阅读原文，更多技术干货，请访问腾云阁。