MySQL 8.4 LTS来了！从8.0到8.4，DBA必须知道的5个核心变化

MySQL 8.0的生命周期实际上已经画上了句号。按照Oracle官方的支持政策，从2026年4月开始，MySQL 8.0社区版就进入了所谓的“永续支持”阶段——说白了，就是不再提供公开的安全更新和漏洞修复了。继续抱着8.0不放，风险只会一天天累积。

那么，该往哪个版本迁移？答案很明确：

。

2024年4月30日发布的MySQL 8.4，是MySQL历史上第一个真正意义上的长期支持版本。5年的超长支持周期（一直到2031年），每年两次补丁更新，而且8.4系列主攻安全性与稳定性——对生产环境来说，这比什么都重要。

下面从五个维度来拆解一下，从8.0到8.4到底变了什么。

一、InnoDB并行查询：从“实验品”到“生产力”

这是8.4对性能提升最显著的地方，也是解决大表查询慢问题的关键武器。

InnoDB并行查询最早出现在8.0.30版本，但当时只是试验性功能。问题出在分片算法上——数据分布不均，经常出现“有人闲死、有人忙死”的情况，查询到最后阶段，总是拖着一个长长的尾巴线程。

8.4 LTS把并行查询这块彻底固化了，做了大量深度优化。核心改进在于

：先按数据量把B+树切成相对均衡的大块预分配，执行过程中再动态拆分剩余任务。实测效果相当漂亮——一张1亿行的订单表，运行COUNT(*)从单线程的1.82秒直接降到16线程的0.22秒，提速超过8倍。而且不需要改业务SQL，也不用搞分库分表。

配置起来也不复杂，关键参数就三个：

• parallel_query：总开关，8.4默认开启
• parallel_threads_limit：单条查询最大worker线程数，默认4，上限64
• innodb_parallel_read_threads：实例全局并行扫描线程池大小，默认是CPU逻辑核数除以8

建议先用EXPLAIN ANALYZE验证一下，看看Extra字段里有没有出现Using parallel scan (N workers)——出现了，就说明生效了。

二、Redo Log动态容量：告别“停机调参”

在8.0时代，调整Redo Log的大小可以说是核心业务系统的一场“开胸手术”——必须停机、修改配置文件、重启实例。尤其是对24×7运行的业务来说，每次调整都让人头疼。

8.4引入了innodb_redo_log_capacity系统变量，

。

新的容量计算方式也发生了变化。如果没有手动设置，Redo Log容量会根据CPU逻辑核数自动计算——(可用逻辑处理器数/2)GB，最大上限16GB。InnoDB内部会自动维护32个大小相同的Redo Log文件，每个文件大小为总容量的1/32。这意味着升级之后，Redo Log会自适应硬件配置，DBA们再也不用摸着石头过河了。

三、默认认证插件变更：小心连不上！

这一点升级时必须重点关注，否则可能会被坑到。

8.4默认不再启用已弃用的mysql_native_password认证插件。如果应用或工具依然依赖旧认证方式——比如一些老版本的JDBC驱动、PHP扩展、Na vicat等客户端——升级后大概率会报连接失败。

要想兼容旧认证，必须在配置文件中加入mysql_native_password=ON。不过稳妥的做法是：

，免得到时手忙脚乱。

四、InnoDB参数默认值大幅调整

8.4对多个InnoDB系统变量的默认值也做了调整。几个关键变化如下：

参数	8.0默认值	8.4默认值	影响
innodb_buffer_pool_instances	8	CPU核数的1/4（1-64）	大内存实例性能提升
innodb_change_buffering	all	none	减少后台IO，但可能影响写入性能
innodb_redo_log_capacity	基于内存计算	基于CPU计算	自动适配硬件
innodb_dedicated_server	OFF	ON（自动检测）	专用服务器自动优化

升级之后建议用SHOW VARIABLES比较一下新旧默认值，确认是否符合业务预期。

五、云原生与AI能力的前瞻布局

8.4在云原生方向上也做了架构上的储备。

：8.4的架构设计已经为存储计算分离预留了空间。据预测，到2026年，超过60%的企业将会采用Serverless形态的数据库服务。8.4的这一设计，算是提前为这个转型铺好了路。

：8.4还内置了一个实验性的AI驱动参数调优功能。虽然现在还是实验特性，但方向已经很清晰——数据库正从“人调参”走向“AI调参”。

：8.4新增了直方图自动更新功能。创建直方图时指定AUTO UPDATE后，当表数据量发生足够变化时，优化器会自动重建直方图，统计信息始终保持准确。对于DBA来说，终于不用再定期手动ANALYZE TABLE了。

升级前必须检查的5件事

准备动手升级前，下面这个清单建议先过一遍：

1. 运行升级检查器
   ：MySQL Shell内置的升级检查工具可以自动检测实例是否准备好升级。建议先跑一遍，把报告列出的问题全部解决，再动手。

2. 检查认证插件兼容性
   ：确认所有应用连接使用的认证方式。如果还在用mysql_native_password，要么迁移到caching_sha2_password，要么确保8.4配置中启用了旧认证。

3. 检查表结构兼容性
   ：8.4不再支持FLOAT和DOUBLE列上的AUTO_INCREMENT。如果表结构中有类似定义，升级前必须改掉。另外，分区键中也不允许使用前缀索引。

4. 检查外键约束
   ：8.4要求父表被引用的列必须有唯一键。如果8.0中存在不符合此规则的外键，升级会失败。

5. 检查MySQL Connector/驱动版本
   ：确认使用的驱动版本兼容8.4。老版本驱动可能不认识8.4的新认证方式或新特性。

总而言之，8.4 LTS不是8.0的一个小补丁，而是

。InnoDB并行查询让大表查询不再依赖分库分表，Redo Log动态容量让调参不再需要停机，存算分离的设计也让后续的云原生转型有了坚实基础。MySQL 8.0的生命周期已经正式结束，现在确实是认真规划升级路径的时候了。