MySQL 8.0.3 RC 版即将发布，看看有哪些变化

emqtt服务器的介绍在官方网站有说明，到目前为止我也没仔细看，不过里面已经详细介绍了如何部署在各种 *** 作系统上，包括编译的方法，源代码的仓库在这里。

首先我们搞清楚emqtt服务器与abc-auth-mysql插件的部署位置，我们在本地编译emqtt服务器；

根据emqtt服务器中Makefile的说明，编译过程中会引入插件abc-auth-mysql的源码并且编译，然而该源码的位置是放置在一个远程的git仓库中的；

所以我们必须先将之前改好的abc-auth-mysql插件源码推送到一个另外的git仓库中；

按照这个网站中的说明，修改emqtt服务器中的文件，将abc-auth-mysql加入到插件列表中；

然后在本地编译整个emqtt服务器；

上述步骤相对比较简单，就不一一赘述了，说一下可能遇到的坑：

比如说编译的时候有一步会卡在mix local.hex这个地方，然后报错，如果遇到，首先尝试翻墙处理，还是不行，自己把mix装好，mix是elixir里面的一个什么东西，装mix好像是要装elixir，装好之后，还可能local.hex这个文件下不下来，这篇文章里面会说是怎么回事，要么翻墙能搞定，要么就等一天，我就是第二天再编译又可以的。。

MySQL支持JSON数据类型。相比于Json格式的字符串类型，JSON数据类型的优势有：

存储在JSON列中的任何JSON文档的大小都受系统变量 max_allowed_packet 的值的限制，可以使用 JSON_STORAGE_SIZE() 函数获得存储JSON文档所需的空间。

在MySQL8.0中，优化器可以执行JSON列的局部就地更新，而不用删除旧文档再将整个新文档写入该列。局部更新的条件：

JSON数组包含在 字符 [ 和 ] 字符中，其中为一个由逗号分隔的值列表：

JSON对象包含在字符 { 和 } 字符中，其中为一组由逗号分隔的键值对，键必须是字符串：

在JSON数组和JSON对象的值中允许嵌套：

下例中向创建一个只有一个JSON列的表格 t_json ，并向其中添加JSON值：

若添加的值为非JSON格式，则报错：

查看 t_json :

如果传入的参数不能组成键值对，则报错：

因此我们也可以使用以上三种方法向表中添加JSON值，可以一定程度地避免输入格式错误：

解析字符串并发现字符串是有效的JSON文档时，它在被解析时也会被规范化。对于重复的键（ key ）,后面的值（ value ）会覆盖前面的值。如下：

这种“覆盖”在向JSON列添加值时也会发生。

在MySQL8.0.3之前的版本中，与此相反，对于被重复的键，它的第一个值会被保留，后添加的值则会被抛弃。

MySQL8.0.3及更高版本中，有两种合并函数： JSON_MERGE_PRESERVE() 和 JSON_MERGE_PATCH() 。下面具讨论它们的区别。

合并数组时， JSON_MERGE_PRESERVE 只保留最后传入的数组参数，而 JSON_MERGE_PRESERVE 则按传入顺序将数组参数连接。

合并对象时，对于重复键， JSON_MERGE_PRESERVE 只保留最后传入的键值，而 JSON_MERGE_PRESERVE 重复键的所有值保留为数组。

在了解搜索和修改JSON值之前，先来看看JSON的路径语法。

JSON_EXTRACT 提取JSON值，直接看例子：

JSON_REPLACE 与 JSON_SET 的区别：

JSON_INSERT 和 JSON_SET :

JSON_REMOVE :

可以使用 = ， <， <= ， >， >= ， <>， != ，和 <=>对JSON值进行比较。

JSON值的比较先比较值的类型。如果类型不同，则直接 返回类型的优先级的比较结果；如果类型相同，再进行值的内容的比较。

OPAQUE 值是不属于其他类型的值。

转换规则为：

caching_sha2_password认证插件提供更多的密码加密方式，并且在加密方面具有更好的表现，目前MySQL 8.0选用caching_sha2_password作为默认的认证插件，MySQL 5.7的认证插件是MySQL_native_password。如果客户端版本过低，会造成无法识别MySQL 8.0的加密认证方式，最终导致连接问题。

MySQL存储引擎现在负责提供自己的分区处理程序，而MySQL服务器不再提供通用分区支持，InnoDB和NDB是唯一提供MySQL 8.0支持的本地分区处理程序的存储引擎。 如果分区表用的是别的存储引擎，存储引擎必须进行修改。要么将其转换为InnoDB或NDB，要么删除其分区。通过MySQLdump从5.7获取的备份文件，在导入到8.0环境前，需要确保创建分区表语句中指定的存储引擎必须支持分区，否则会报错。

MySQL 8.0的默认字符集utf8mb4，可能会导致之前数据的字符集跟新建对象的字符集不一致，为了避免新旧对象字符集不一致的情况，可以在配置文件将字符集和校验规则设置为旧版本的字符集和校验规则。

MySQL 8.0启动使用的lower_case_table_names值必须跟初始化时使用的一致。使用不同的设置重新启动服务器会引入与标识符的排序和比较方式不一致的问题。

< lower_case_table_names >

https://dev.mysql.com/doc/refman/8.0/en/server-systemvariables.html#sysvar_lower_case_table_names

要避免MySQL 8.0上的启动失败，MySQL配置文件中的sql_mode系统变量不能包含NO_AUTO_CREATE_USER。

从MySQL 5.7.24和MySQL 8.0.13开始，MySQLdump从存储程序定义中删除了NO_AUTO_CREATE_USER。必须手动修改使用早期版本的MySQLdump创建的转储文件，以删除NO_AUTO_CREATE_USER。

在MySQL 8.0.11中，删除了这些不推荐使用的兼容性SQL Mode：DB2，MAXDB，MSSQL，MySQL323，MySQL40，ORACLE，POSTGRESQL，NO_FIELD_OPTIONS，NO_KEY_OPTIONS，NO_TABLE_OPTIONS。从5.7到8.0的复制场景中，如果语句使用到废弃的SQL Mode会导致复制异常。

在执行到MySQL 8.0.3或更高版本的in-place升级时，BACKUP_ADMIN权限自动授予具有RELOAD权限的用户。

本文对MySQL 5.7到MySQL 8.0的升级过程中出现部分易出现问题进行整理：升级对MySQL版本的要求、升级都做了哪些内容、数据库升级做了哪些步骤以及注意事项，希望对大家版本升级有帮助。

---