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 中删除的功能

1. MySQL 9.0 中添加或更改的功能

MySQL 9.0 添加了以下功能

• 保存 EXPLAIN 分析 JSON 输出
• DDL 语句新增 Event 语法
• 性能模式新添加了两个新表

1.1. 保存 EXPLAIN 分析 JSON 输出

从 MySQL 9.0.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）。

1.1.1. 解释

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

mysql> EXPLAIN FORMAT=JSON INTO @myselect 
    ->     SELECT name FROM a WHERE id = 2;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT @myselect\G
*************************** 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() 的示例所示：

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。

1.2. DDL 语句新增 Event 语法

从 MySQL 9.0.0 开始，可以使用以下 Event 语法：

• CREATE EVENT（创建事件）
• ALTER EVENT（修改事件）
• DROP EVENT（删除事件）

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

EVENT 语句语法如下，

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 语句得语法看着比较复杂，参数众多，实际掌握一些常用参数就好了。常用语法如下，

CREATE EVENT 事件名
    ON SCHEDULE AT 或者 EVERY + 指定时间间隔
    DO 接 SQL 语句

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

1.2.1. 解释

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

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。

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

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）设置的属性及其值的信息用表格式用作展示。

1.3.1. 解释

性能模式新添加的两个新表就是方便大家直接在 MySQL cli 模式中直接查询系统变量以及全局变量。

有关这两个表的详细说明，大家可以参阅官网 https://dev.mysql.com/doc/refman/9.0/en/performance-schema-system-variable-tables.html。

2. 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 章节）。

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 插件。

3.1. mysql_native_password 介绍

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

3.2. 删除起因

在这之前 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 加密很耗费时间。虽然安全性更高，但是验证速度不够快。

3.3. 改进

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

4. 总结

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 在数据库领域的领先地位，为数据库应用带来更多可能性。