MySQL 8.4 变化概览

MySQL 8.0 由于在 2026 年 4 月停止维护, 这导致一些云厂商的 MySQL 服务可能面临强制升级的风险, 比如 aws 的声明 MySQL-VersionMgmt:

备注: aws 的 Extended Support 是额外收费的服务, 并非免费.

鉴于此原因, 本文汇总了 MySQL 8.0 到 MySQL 8.4 之间的主要变化. 而 MySQL 5.7 到 MySQL 8.0 的变化可以参考之前的文章 MySQL 8.0 特性概览.

• 权限变化
• 数据类型
• 外键变化
• InnoDB 变化
• 主从变化
• 高可用及切换
• mysqldump 备份
• 协议交互
• 其它变化
• 参考

权限变化

在 MySQL 8.4 中, 已经默认禁止了 mysql_native_password 认证插件, 如果业务需要, 可以显示的指定选项:

mysql_native_password=ON

另外, 旧版本的 SET_USER_ID 权限允许用户对 procedure/trigger/events 指定 DEFINER 用户, 在 8.4 中被拆分为以下两个权限:

SET_ANY_DEFINER
ALLOW_NONEXISTENT_DEFINER

数据类型

自增列(AUTO_INCREMENT) 使用 FLOAT 或 DOUBLE 类型会直接报错.

外键变化

8.0 中外键仅允许关联父表的索引(没有唯一性要求), 但在 8.4 中, 除了仅关联父表的索引, 还必须唯一. 不过唯一性可以由变量 restrict_fk_on_non_standard_key 控制.

InnoDB 变化

主要参数和选项变化

主从变化

8.4 中主从的关键字和语法有了变化:

主从相关的系统状态变量也有了变化:

但是 slave 的权限依旧是:

REPLICATION SALVE
REPLICATION CLIENT

开启 GTID 的选项依旧是:

gtid_mode=ON
enforce-gtid-consistency=ON

但 CHANGE 语句有了变化, 如下所示:

mysql> CHANGE REPLICATION SOURCE TO
    ->     SOURCE_HOST='source_host_name',
    ->     SOURCE_USER='replication_user_name',
    ->     SOURCE_PASSWORD='replication_password',
    ->     GET_SOURCE_PUBLIC_KEY=1,  -- 如果 master 中的 repl 用户是 caching_sha2_password 验证, 可以设置此选项, 允许获取 source 的 RSA 公钥.
    ->     SOURCE_LOG_FILE='recorded_log_file_name',
    ->     SOURCE_LOG_POS=recorded_log_position;
    
mysql> CHANGE REPLICATION SOURCE TO
     >     SOURCE_HOST = host,
     >     SOURCE_PORT = port,
     >     SOURCE_USER = user,
     >     SOURCE_PASSWORD = password,
     >     GET_SOURCE_PUBLIC_KEY=1,  -- 如果 master 中的 repl 用户是 caching_sha2_password 验证, 可以设置此选项, 允许获取 source 的 RSA 公钥.
     >     SOURCE_AUTO_POSITION = 1;

维护语句也变更为:

STOP REPLICA;
START REPLICA;
SHOW REPLICA STATUS;'

高可用及切换

由于主从语句有变化, 常用的主从管理工具(mha4mysql-manager 和 orchestrator) 已不再维护, 需要自行按需定制修改.

mysqldump 备份

8.4 版本 mysqldump 新增选项 --output-as-version , 在备份 8.4 版本数据库时, 可以生成与旧版本(BEFORE_8_0_23 或 BEFORE_8_2_0)兼容的 SQL 文件. 另外以下几个选项也值得注意:

协议交互

直接 telnet 8.4 版本, 可以看到返回的是 caching_sha2_password 认证的头信息,

# telnet 10.1.1.34 3396
Trying 10.1.1.34...
Connected to 10.1.1.34.
Escape character is '^]'.
K
8.4.5-5O-@
        IXy-BOy23F
aching_sha2_password^]
telnet> quit

备注: 8.0 中, 如果没有修改 default_authentication_plugin, telnet 也会是同样的消息.

这种模式下, 如果连接的用户使用的是 mysql_native_password 验证, 会再进行协商选择. 比起以前的方式, connection 阶段会多一些交互. 更多见: mysql-8.4-connection_phase.

多出的这些交互可能会引起一些低版本(支持 <= 8.0 版本 mysql)的库解析协议数据出错, 比如:

 // 解析的数据中 sequence id 对应不上
 2025/08/22 11:59:10 creata.table.error[pkt.read.seq[3]!=pkt.actual.seq[1] (errno 1835) (sqlstate HY000)]
 panic: creata.table.error[pkt.read.seq[3]!=pkt.actual.seq[1] (errno 1835) (sqlstate HY000)]

对应的 MySQL 则返回错误: Got packets out of order. 这种情况下只能通过更新 lib 库来解决.

另外 8.0 版本由于可以直接设置 default_authentication_plugin = mysql_native_password, 这种情况下 connection 阶段没有多余的交互, 低版本的 lib 库不会出错.

其它变化

AHU 功能

8.4 支持 Automatic Histogram Updates(ANALYZE TABLE AUTO UPDATE), 可以自动让统计的状态保持最新, 有利于查询优化.

GTID Tags

允许标记事务组, 用来提升 replication 中的跟踪和审计.

FLUSH_PRIVILEGES 权限

新增 FLUSH_PRIVILEGES 权限, 允许执行对应 FLUSH PRIVILEGES 语句的权限.

FLUSH HOSTS 变化

8.4 中变更为语句 TRUNCATE TABLE performance_schema.host_cache.

Keyring 迁移

8.4 支持将 Keyring 组件迁移到插件中. 更多见: Keyring Components Versus Keyring Plugins.

Performance Schema 变化

1. 表 INFORMATION_SCHEMA.PROCESSLIST

在 8.0.35, 8.2.0 版本已废弃, 未来的版本可能删掉. 8.4 版本则两个系统状态变量来表示 processlist 表的访问状态:

更多见 8.4-processlist-table.

2. 表 INFORMATION_SCHEMA.TABLESPACES

在 8.0.22 中已经废弃, 在 8.4 版本中已经移除.

更多启动/关闭相关的日志消息

8.4 在服务初始化, Innodb 初始化, 崩溃恢复, 插件安装卸载等方面增加了更多的日志消息.

unix_timestamp 函数变化

从 8.0.22 开始, unix_timestamp 函数出现了一些变化, 如下所示:

select
  now() as a,
  '2025-09-18' as b, 
  date_format(now(), '%Y-%m-%d') as c,
  unix_timestamp(date_format(now(), '%Y-%m-%d')) as d, 
  unix_timestamp(CAST(date_format(now(), '%Y-%m-%d') AS date)) as e, 
  unix_timestamp(date_format('2025-09-18 10:35:31', '%Y-%m-%d')) as f, 
  unix_timestamp(now()) as g, 
  unix_timestamp(date_format(CONCAT('2025-09-18', SPACE(1), '10:40:27'), '%Y-%m-%d %H')) as h, 
  unix_timestamp(date_format(CONCAT(current_date(), SPACE(1), current_time()), '%Y-%m-%d %H')) as i
from 
  dual\G
  
*************************** 1. row ***************************
a: 2025-09-18 10:45:00
b: 2025-09-18
c: 2025-09-18
d: 1758124800.000000
e: 1758124800
f: 1758124800
g: 1758163500
h: 1758160800
i: 1758160800.000000

d 和 i 的结果跟我们预想的不一样, 函数的参数并未有小数, 最终结果却是保留了 6 位小数. 这种模式可能此类 sql 查询的业务出现异常. 不过这并非 bug, 参考 bug-10847, 即从 8.0.22 开始, unix_timestamp 的结果会根据参数中的表达式字面值来判断, 明显位字符串的返回预期的值, 否则将表达式结果当做 DECIMAL 类型处理, 最终返回包含 6 位小数的结果.

In order to determine the exact number of decimals (zero in case of an integer), we need the 
expression to be consisting of only literal values. In this case, it is only cases f and g 
that qualifies for that. Cases d, e and h contains expressions that may vary at execution time 
and hence are assigned type DECIMAL and with 6 decimals.

It is indeed the UNIX_TIMESTAMP function that returns the numeric type. DATE_FORMAT always 
returns a character string.

It changed in 8.0.22. Before that, types could be determined more specifically based on literal 
values, user variables and parameter values. Starting with 8.0.22, such specific typing is only 
possible for literal values. The reason was to get more predictable types for prepared statements.

参考

更多见:

What Is New in MySQL 8.4 since MySQL 8.0
What’s New in MySQL 8.4 LTS: Key Enhancements Explained