MySQL 5.7与8.0版本在安装流程和默认认证插件上的区别

从 MySQL 5.7 跨越到 MySQL 8.0，运维人员最常遇到的两个直接阻碍是初始化命令与文件结构的调整，以及老客户端连入时弹出的“Authentication plugin 'caching_sha2_password' cannot be loaded”报错。本文直接拆解两者在安装初始化流程、数据字典架构差异以及默认认证插件机制上的实质变化与具体应对方案。

安装与初始化阶段的核心流程区别

在解压二进制包进行安装时，MySQL 5.7 曾经保留着来自更早版本的遗留工具 mysql_install_db，尽管官方在 5.7 中引入了 mysqld --initialize，但两种方式仍可混用。而在 MySQL 8.0 中，mysql_install_db 已经被完全彻底移除，服务初始化统一收敛为 mysqld 命令自身完成。

在空数据目录初始化过程中，命令参数的选择决定了初始密码的生成逻辑。5.7 与 8.0 在这一命令体系上保持了一致的参数名，但 8.0 对初始化环境的检查更加严苛：目标 datadir 必须是绝对干净的空目录，或者根本不存在，否则初始化会直接终止报错。

初始化命令示例如下：

# 进入 MySQL 根目录执行初始化
bin/mysqld --initialize --user=mysql --basedir=/usr/local/mysql --datadir=/data/mysql

执行完成后，控制台不会直接打印口令。程序会自动生成一个随机临时密码并输出到指定的 log-error 错误日志中：

# 示例输出：从错误日志提取临时口令
grep 'temporary password' /data/mysql/error.log
# [Note] A temporary password is generated for root@localhost: Yk8+eQ-jL9aZ

数据目录文件结构与元数据存储的剧变

在安装完成并初始化数据目录后，观察 datadir 会发现两者底层设计存在本质区别。在 MySQL 5.7 及以前，每个表都会在所属数据库目录下生成一个对应的 .frm 文件来保存表结构定义，涉及的分区表还有 .par 文件，MyISAM 引擎还有 .MYD 与 .MYI 文件。系统元数据则分散存放在系统表空间以及基于 MyISAM 的系统表中。

而在 MySQL 8.0 中，官方引入了统一的**事务型数据字典（Transactional Data Dictionary）**。所有的 .frm、.par 文件全部被淘汰，元数据统一存放在 InnoDB 表空间的内部系统表中。与此同时，8.0 引入了序列化字典信息（Serialized Dictionary Information，简称 SDI），在独立的表空间（.ibd）内自包含表元数据。

默认认证插件机制的演进与握手逻辑

这是两个版本在应用接入层最为显著的分水岭。在 MySQL 5.7 中，新建用户的默认认证插件是 mysql_native_password。该插件采用两次 SHA-1 哈希计算并配合加盐验证，计算开销低，兼容性广泛，但无法抵御暴力破解和特定彩虹表攻击。

从 MySQL 8.0.4 开始，默认认证插件切换为 caching_sha2_password。它采用安全性更高的 SHA-256 算法，并结合客户端与服务端的随机数加盐派生密钥。同时，为了解决 SHA-256 相对较高的 CPU 算力开销问题，该插件在服务端内存中开辟了缓存层：一旦用户在当前服务器握手成功一次，后续认证直接走内存哈希比对，快速放行。

驱动不兼容报错排查与降级配置

当旧版应用程序（如较老版本的 Navicat、旧版 PHP 驱动 pdo_mysql、老版本 mysql-connector-java 5.1.x）尝试连接 MySQL 8.0 时，最常遭遇如下报错：

# 典型报错信息
java.sql.SQLException: Unable to load authentication plugin 'caching_sha2_password'
# 或者：
Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.

该问题的根本原因在于，老驱动内部只写死了 mysql_native_password 协议解析代码，没有内置 SHA-256 算法和 RSA 公钥请求能力。处理该问题有两种方案：升级客户端或降级服务端用户。

方案一：针对特定用户单独指定兼容插件（推荐）

不建议直接改动全局配置，而是针对需要外部老客户端连接的业务账号，单独将其认证插件切换为 mysql_native_password：

-- 查看当前所有用户的插件类型
SELECT user, host, plugin FROM mysql.user;

-- 将特定用户降级为 mysql_native_password 并重新设密
ALTER USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'StrongPassword123!';

-- 刷新权限使之生效
FLUSH PRIVILEGES;

方案二：修改服务器全局默认认证插件

若系统部署有大量无法重构的老旧程序，可在 my.cnf 或 my.ini 中强制指定全局默认配置：

[mysqld]
# 强制将默认认证插件改回 5.7 风格（仅对配置文件生效后新建的用户有效）
default_authentication_plugin = mysql_native_password

差异总结与选型参考

为了直观掌握版本间的变化脉络，以下将二者在生命周期各关键环节的差异汇总对比如下：

在生产环境部署时，如果当前业务系统配套的连接池或中间件（如老版本 MyCat、老版本 PHP 5.x 运行环境）无法跟随升级，在 8.0 服务端建立账号时显式指定 IDENTIFIED WITH mysql_native_password 是成本最低的平滑过渡策略；而对于新启动的系统，应直接升级驱动库，充分利用 caching_sha2_password 带来的安全性与缓存性能优势。