MySQL 9.0 GA 来了!

2024-07-04 13:47:24 浏览数 (1)

2024 年 7 月 2 日,MySQL 9.0 GA 版本正式发布。还记得 MySQL 8.0 版本正式发布于 2018 年 4 月 19 日,中间经过了 6 年之久,MySQL 官方终于发布了大版本号变更得 9.0 版本,接下来由我给大家介绍 MySQL 在 9.0 版本中有哪些新的变化。 本文包含如下内容:

  • MySQL 9.0 中添加或更改的功能
  • MySQL 9.0 中已弃用的功能
  • MySQL 9.0 中删除的功能

MySQL 9.0 中添加或更改的功能

MySQL 9.0 添加了以下功能

  • 保存 EXPLAIN 分析 JSON 输出EXPLAIN ANALYZE FORMAT=JSON INTO @variable select_stmt随后,该变量可用作任何 MySQL JSON 函数的 JSON 参数( Section 15.1.13, “CREATE EVENT Statement”)。只有 FORMAT=JSON 时才支持 INTO 子句;必须明确指定 FORMAT。这种形式的 EXPLAIN ANALYZE 还支持可选的 FOR SCHEMA 或 FOR DATABASE 子句。注意:仅当 explain_json_format_version 服务器系统变量设置为2时,此功能才可用;否则,尝试使用它会引发 ER_EXPLAIN_ANALYZE_JSON_FORMAT_VERSION_NOT_SUPPORTED (EXPLAIN ANALYZE 不支持 FORMAT=JSON 且解释_json_format_version=1)。
  • DDL 语句新增 Event 语法
  • 性能模式新添加了两个新表 <a name="mktlz"></a>保存 EXPLAIN 分析 JSON 输出从 MySQL 9.0.0 开始,现在支持使用下方得新语法 将 EXPLAIN 分析的 JSON 输出保存到用户变量中:
解释

这里直接给大家看看官网得例子,方便理解

代码语言:sql复制
mysql> EXPLAIN FORMAT=JSON INTO @myselect 
    ->     SELECT name FROM a WHERE id = 2;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @myselectG
*************************** 1. row ***************************
@myex: {
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "1.00"
    },
    "table": {
      "table_name": "a",
      "access_type": "const",
      "possible_keys": [
        "PRIMARY"
      ],
      "key": "PRIMARY",
      "used_key_parts": [
        "id"
      ],
      "key_length": "4",
      "ref": [
        "const"
      ],
      "rows_examined_per_scan": 1,
      "rows_produced_per_join": 1,
      "filtered": "100.00",
      "cost_info": {
        "read_cost": "0.00",
        "eval_cost": "0.10",
        "prefix_cost": "0.00",
        "data_read_per_join": "408"
      },
      "used_columns": [
        "id",
        "name"
      ]
    }
  }
}
1 row in set (0.00 sec)

大家都知道 EXPLAIN 可以用于分析 SQL 语句,在 MySQL 9.0 中,EXPLAIN 得语法发生了变化,在查询语句 EXPLAIN FORMAT=JSON INTO @myselect SELECT name FROM a WHERE id = 2中,EXPLAIN 后面可以接上 FORMAT=JSON INTO @myselect 语句,这样我们将 EXPLAIN 得输出结果保存到变量 myselect 中。 在保存到变量 myselect 中后,我们就可以使用 MySQL JSON 函数处理该变量,就像处理任何其他 JSON 值一样,如以下使用 JSON_EXTRACT() 的示例所示:

代码语言:sql复制
mysql> SELECT JSON_EXTRACT(@myselect, "$.query_block.table.key");
 ---------------------------------------------------- 
| JSON_EXTRACT(@myselect, "$.query_block.table.key") |
 ---------------------------------------------------- 
| "PRIMARY"                                          |
 ---------------------------------------------------- 
1 row in set (0.01 sec)

mysql> SELECT JSON_EXTRACT(@myupdate, "$.query_block.table.access_type") AS U_acc,
    ->        JSON_EXTRACT(@mydelete, "$.query_block.table.access_type") AS D_acc;
 --------- ------- 
| U_acc   | D_acc |
 --------- ------- 
| "range" | "ALL" |
 --------- ------- 
1 row in set (0.00 sec)

关于 EXPLAIN 语句更多新的使用方式,大家可以参阅https://dev.mysql.com/doc/refman/9.0/en/explain.html#explain-execution-plan。

DDL 语句新增 Event 语法

从 MySQL 9.0.0 开始,可以使用以下 Event 语法:

  • CREATE EVENT(创建事件)
  • ALTER EVENT(修改事件)
  • DROP EVENT(删除事件)

EVENT 语句不支持使用占位符参数(?)。我们必须根据字符串文字、系统变量和用户变量的某种组合来组装要准备的语句文本。 EVENT 语句语法如下,

代码语言:sql复制
CREATE
    [DEFINER = user]
    EVENT
    [IF NOT EXISTS]
    event_name
    ON SCHEDULE schedule
    [ON COMPLETION [NOT] PRESERVE]
    [ENABLE | DISABLE | DISABLE ON {REPLICA | SLAVE}]
    [COMMENT 'string']
    DO event_body;

schedule: {
    AT timestamp [  INTERVAL interval] ...
  | EVERY interval
    [STARTS timestamp [  INTERVAL interval] ...]
    [ENDS timestamp [  INTERVAL interval] ...]
}

interval:
    quantity {YEAR | QUARTER | MONTH | DAY | HOUR | MINUTE |
              WEEK | SECOND | YEAR_MONTH | DAY_HOUR | DAY_MINUTE |
              DAY_SECOND | HOUR_MINUTE | HOUR_SECOND | MINUTE_SECOND}

EVENT 语句得语法看着比较复杂,参数众多,实际掌握一些常用参数就好了。常用语法如下,

代码语言:sql复制
CREATE EVENT 事件名
    ON SCHEDULE AT 或者 EVERY   指定时间间隔
    DO 接 SQL 语句

EVENT 后面跟事件名,ON SCHEDULE 后面可以跟 AT 或者 EVERY 表示指定时间或者每隔一段时间,DO 后面接 SQL 语句,表示当满足时间条件后要执行得 SQL 语句。

解释

Event 语句提供得功能跟定时任务相似,它可以在 MySQL 中定时执行一些 SQL 语句。还可以用于 MySQL 得存储过程中。接下来给大家提供一个官网例子,供大家理解,

代码语言:sql复制
CREATE EVENT myevent
    ON SCHEDULE AT CURRENT_TIMESTAMP   INTERVAL 1 HOUR
    DO
      UPDATE myschema.mytable SET mycol = mycol   1;

上面的语句创建了一个名为 myevent 的事件。该事件执行一次(创建后一小时),方法是运行一条 SQL 语句,将 myschema.mytable 表的 mycol 列的值加 1。 关于 Event 语法更多新的使用方式,大家可以参阅 https://dev.mysql.com/doc/refman/9.0/en/create-event.html。

性能模式新添加了两个新表

Variables_metadata 表 Variables_metadata 表提供有关系统变量的一般信息。此信息包括 MySQL 服务器识别的每个系统变量的名称、范围、类型、范围(如果适用)和描述。 该表中的两列(MIN_VALUE 和 MAX_VALUE)旨在替换 Variables_info 表中已弃用的列。

Variables_metadata 表显示每个服务器系统变量的名称、范围、类型、值范围(如果适用)和说明。

global_variable_attributes 表 global_variable_attributes 表提供有关服务器分配给全局系统变量的属性值对的信息。

global_variable_attributes 表就是把 MySQL 服务器已为全局变量(例如offline_mode 或read_only)设置的属性及其值的信息用表格式用作展示。

解释

性能模式新添加的两个新表就是方便大家直接在 MySQL cli 模式中直接查询系统变量以及全局变量。 有关这两个表的详细说明,大家可以参阅官网 https://dev.mysql.com/doc/refman/9.0/en/performance-schema-system-variable-tables.html。

MySQL 9.0 中已弃用的功能

以下功能在 MySQL 9.0 中已弃用,并且可能会在未来的系列中删除。如果 MySQL 更新说明中有显示替代方案,则你们应更新应用程序并使用它们。 对于使用 MySQL 9.0 中已弃用且已在更高 MySQL 版本中删除的功能的应用程序,从 MySQL 9.0 源复制的语句到运行更高版本的副本时,语句可能会执行失败,或者可能对源和副本产生不同的影响。为了避免此类问题,应修改使用 9.0 中已弃用功能的应用程序以避免这些问题,并尽可能使用替代方案。以下内容为弃用功能,

性能模式 variables_info 表列。 性能模式变量信息表的 MIN_VALUE 和 MAX_VALUE 列现已弃用,并且可能会在未来的 MySQL 版本中删除。相反请使用 Variables_metadata 表中具有相同名称的列(请参阅上文 1.3 章节)。

MySQL 9.0 中删除的功能

以下功能已过时并已在 MySQL 9.0 中删除。如果 MySQL 更新说明中有显示替代方案,则你们应更新应用程序并使用它们。 对于使用 MySQL 9.0 中删除的功能的 MySQL 8.4 应用程序,从 MySQL 8.4 源复制到 MySQL 9.0 副本时,语句可能会执行失败,或者可能对源和副本产生不同的影响。为了避免此类问题,应修改使用 MySQL 9.0 中删除的功能的应用程序以避免这些问题,并尽可能使用替代方案。

mysql_native_password 插件。mysql_native_password 身份验证插件已在 MySQL 8.0 中弃用,已被删除。服务器现在拒绝来自不具有 CLIENT_PLUGIN_AUTH 功能的旧客户端程序的 mysql_native 身份验证请求。 由于此更改,以下服务器选项和变量也已被删除:

  • --mysql-native-password 服务器选项
  • --mysql-native-password-proxy-users 服务器选项
  • default_authentication_plugin 服务器系统变量

给大家介绍一下 mysql_native_password 插件。

mysql_native_password 介绍

从 MySQL 8.0.4 开始,MySQL 默认身份验证插件从 mysql_native_password 改为 caching_sha2_password 。相应地,libmysqlclient 也使用 caching_sha2_password 作为默认的身份验证机制。

删除起因

在这之前 MySQL 5.6/5.7 使用的默认密码插件是 mysql_native_password。mysql_native_password 的特点是不需要加密的连接。该插件验证速度特别快,但是不够安全,因为,mysql_native_password 使用的是于 SHA1 算法,NIST(美国国家标准与技术研究院)在很早之前就已建议停止使用 SHA1 算法,因为 SHA1 和其他哈希算法(例如 MD5)容易被破解。 其实从 MySQL 5.6 开始就引入了更安全的认证机制:ha256_password 认证插件。它使用一个加盐密码(salted password)进行多轮 SHA256 哈希(数千轮哈希,暴力破解更难),以确保哈希值转换更安全。但是,建立安全连接和多轮 hash 加密很耗费时间。虽然安全性更高,但是验证速度不够快。

改进

MySQL 试图结合二者的优点。于是在 MySQL 8.0.3 版本引入了一个新的身份验证插件 caching_sha2_password ,作为sha256_password的代替方案,在sha256_password 的基础上进行了改进补上了短板,既解决安全性问题又解决性能问题。与此同时 sha256_password将退出时代的浪潮。MySQL 预计在未来版本中将其删除。使用 sha256_password 进行身份验证的 MySQL 账户建议转为 caching_sha2_password。 其实 MySQl 早就想在 8.0 版本中替换到 mysql_native_password 插件,到了 9.0 版本直接删除 mysql_native_password 功能其实提前跟大家打过招呼。 有关认证插件的更多问题,大家可以参阅官网 https://dev.mysql.com/doc/refman/9.0/en/authentication-plugins.html

总结

MySQL 9.0 版本新增了 EXPLAIN 分析 JSON 输出、DDL 语句新增 Event 语法、性能模式新添加了两个新表,弃用了老版本中的 variables_info 表,删除了 mysql_native_password 认证插件。 这些更新没有带来大的功能改动,对于大多数应用程序来说影响很小,没有当年 MySQL 5.7 发布时带来的 innodb 存储引擎那种给人带来的激动感,更新说明中也没有强调性能改进(估计性能对比 8.4 版本提升不大)。不过这也说明关系型数据库 MySQL 如今的功能以及稳定性方面都已经越来越完善。 OK,这里也是祝贺 MySQL 9.0 GA 版本的发布,MySQL 作为开源界的数据库一哥,地位早已无法撼动。相信新版本将进一步巩固 MySQL 在数据库领域的领先地位,为数据库应用带来更多可能性。

我正在参与2024腾讯技术创作特训营最新征文,快来和我瓜分大奖!

0 人点赞