MySQL 8.0与5.7版本安装及默认认证方式的区别

MySQL 5.7和MySQL 8.0的基本安装思路并没有完全改变：选择正确的软件源或安装包、安装服务器、启动服务，然后设置管理员账号并验证连接。真正容易导致升级或部署失败的差异，集中在默认认证插件上。MySQL 5.7默认使用mysql_native_password，而MySQL 8.0从8.0.4开始默认使用caching_sha2_password。这会直接影响旧版PHP、Java、Python程序以及数据库管理工具能否正常连接。

因此，安装两个版本时不能只确认“服务是否启动”，还应该检查实际版本、账号使用的认证插件以及应用程序所使用的数据库驱动。特别是从5.7升级到8.0时，数据库服务器升级成功并不意味着所有客户端都会自动适配新的认证方式。

先看MySQL 5.7与8.0最关键的区别

安装流程本身有什么不同

如果使用官方软件仓库、Windows安装器或二进制安装包，MySQL 5.7和8.0的安装步骤看起来很接近，但现在安装旧版本5.7时需要特别注意安装源是否真的提供5.7。不能简单执行系统的默认安装命令，然后认为得到的一定是5.7或8.0。

以Debian、Ubuntu类系统为例，在已经正确配置Oracle MySQL APT软件源并选定目标系列之后，安装服务器通常可以执行：

sudo apt-get update
sudo apt-get install mysql-server

安装完成后检查服务：

systemctl status mysql

再确认实际安装版本：

mysql --version

这里最重要的不是记住安装命令，而是在安装之前选定软件源中的版本系列，在安装之后再次检查版本。系统原生仓库和MySQL官方仓库提供的版本可能不同，软件仓库的默认版本也可能随着时间发生变化。

Windows安装时，8.0的认证选项更值得注意

Windows环境使用MySQL Installer安装MySQL 8.0时，8.0.4及之后的版本会涉及认证方式选择。官方推荐的是基于caching_sha2_password的强密码认证方式；如果应用依赖无法支持该认证插件的旧客户端，则历史安装流程中也提供过兼容旧认证方式的选择。

这意味着Windows用户安装8.0时，不能只一路接受默认配置。如果服务器后面要连接老版本PHP程序、旧数据库工具或较老的驱动，应提前确认它们是否支持caching_sha2_password。 :contentReference[oaicite:1]{index=1}

安装完成后不要直接判断root一定使用默认插件

官方APT安装流程本身就可能根据安装时的选择改变root账号行为。例如某些情况下，如果安装过程中没有为root设置密码，本地root访问可能使用Socket Peer-Credential认证。因此，“MySQL 8.0默认是caching_sha2_password”不能简单理解成“任何机器上的root账号一定是caching_sha2_password”。

最可靠的方法是登录数据库后实际查询：

SELECT user, host, plugin
FROM mysql.user
ORDER BY user, host;

你可能看到类似下面这样的结构。这里仅表示结果字段和判断方法，不代表每台服务器都会出现完全相同的账号：

+----------+-----------+-----------------------+
| user     | host      | plugin                |
+----------+-----------+-----------------------+
| app_user | localhost | caching_sha2_password |
| root     | localhost | caching_sha2_password |
+----------+-----------+-----------------------+

如果是在5.7服务器上，新建普通密码账号通常会看到：

mysql_native_password

MySQL 5.7为什么默认使用mysql_native_password

MySQL 5.7的默认认证插件是mysql_native_password。它属于MySQL长期使用的原生密码认证机制，对旧客户端和旧驱动的兼容性很好。官方5.7文档明确将它列为默认认证插件。 :contentReference[oaicite:2]{index=2}

例如在正常使用默认配置的MySQL 5.7中创建账号：

CREATE USER 'app_user'@'localhost'
IDENTIFIED BY 'Example-Password-2026!';

GRANT SELECT, INSERT, UPDATE, DELETE
ON appdb.*
TO 'app_user'@'localhost';

因为没有在CREATE USER语句中明确指定认证插件，所以服务器会使用自己的默认认证插件。对于标准的MySQL 5.7配置，这通常就是mysql_native_password。

可以继续检查：

SELECT user, host, plugin
FROM mysql.user
WHERE user = 'app_user';

MySQL 8.0为什么改成caching_sha2_password

MySQL从8.0.4开始将服务器默认认证插件从mysql_native_password改成caching_sha2_password。MySQL 8.0正式GA版本因此通常都采用这一默认策略。这个插件使用SHA-256相关认证机制，并通过服务器端缓存减少完成认证时的开销。 :contentReference[oaicite:3]{index=3}

在标准MySQL 8.0默认配置下执行：

CREATE USER 'app_user'@'localhost'
IDENTIFIED BY 'Example-Password-2026!';

没有明确写IDENTIFIED WITH时，新账号通常会采用：

caching_sha2_password

随后可以用相同查询确认：

SELECT user, host, plugin
FROM mysql.user
WHERE user = 'app_user';

为什么升级到8.0后旧程序可能突然连不上

这是5.7迁移8.0时最常见的误区之一。数据库端端口正常、用户名正确、密码也没有输错，但应用仍然报告认证失败。这时候问题可能并不在密码，而是客户端驱动根本不认识caching_sha2_password。

MySQL官方8.0文档明确说明，没有更新到支持caching_sha2_password的客户端或Connector，无法正常连接使用该插件的账号。解决问题时应该优先升级数据库驱动，而不是马上降低服务器认证方式。 :contentReference[oaicite:4]{index=4}

排查时先登录数据库查看目标账号：

SELECT user, host, plugin
FROM mysql.user
WHERE user = 'app_user';

如果结果中的插件是：

caching_sha2_password

而应用使用的是多年没有升级的数据库连接组件，就应该继续检查应用驱动版本和该驱动对MySQL 8.0认证协议的支持情况。

优先方案：升级客户端驱动

对于仍在维护的应用，优先升级PHP、Java、Python、Node.js或其他语言使用的MySQL Connector，使其能够原生支持caching_sha2_password。这样服务器可以继续保持8.0的默认认证策略。

排查顺序建议保持为：

1. 确认服务器确实运行MySQL 8.0。
2. 查询故障账号的plugin字段。
3. 确认客户端数据库驱动版本。
4. 确认该驱动支持caching_sha2_password。
5. 确认远程连接是否使用TLS，或客户端是否支持需要的RSA密码交换机制。
6. 升级驱动后重新测试。

兼容旧程序时可以临时改成mysql_native_password

如果旧应用暂时无法升级，而服务器仍处于支持mysql_native_password的MySQL 8.0版本，可以针对特定账号显式使用旧认证插件：

ALTER USER 'app_user'@'localhost'
IDENTIFIED WITH mysql_native_password
BY 'Example-Password-2026!';

修改后再次检查：

SELECT user, host, plugin
FROM mysql.user
WHERE user = 'app_user';

这类做法应该被视为旧系统兼容措施，而不是8.0新项目的默认配置。MySQL已经在8.0.34中将mysql_native_password标记为弃用，因此长期方案仍然应该是更新客户端和应用程序。 :contentReference[oaicite:5]{index=5}

从MySQL 5.7升级到8.0时，旧账号会不会自动改认证方式

不会因为服务器升级就简单地把所有已有账号统一转换成caching_sha2_password。MySQL官方说明，从旧版本升级到8.0后，已有账户原先使用的认证插件会保持不变。默认认证插件的变化主要影响升级以后新创建的账号。 :contentReference[oaicite:6]{index=6}

例如，5.7服务器中已经有：

'legacy_app'@'localhost'
plugin = mysql_native_password

升级到8.0以后，这个账号不会仅因为升级操作就自动变成caching_sha2_password。

但升级以后再创建：

CREATE USER 'new_app'@'localhost'
IDENTIFIED BY 'Example-New-Password-2026!';

在标准的MySQL 8.0默认配置中，new_app通常会使用caching_sha2_password。

于是同一台8.0服务器上完全可能同时存在：

legacy_app    mysql_native_password
new_app       caching_sha2_password

这也是迁移过程中容易造成判断混乱的地方：一个旧应用可以正常连接，并不能证明另一个新账号也一定能被同一套旧驱动正常使用。

如何查看服务器当前默认认证方式

对于MySQL 5.7和MySQL 8.0，可以先尝试查询相关系统变量：

SHOW VARIABLES LIKE 'default_authentication_plugin';

在对应版本和配置中，结果可能显示：

mysql_native_password

或者：

caching_sha2_password

不过在实际运维中，查询服务器默认值还不够。因为真正进行登录认证的是具体用户账号绑定的插件，所以还应该执行：

SELECT user, host, plugin
FROM mysql.user
ORDER BY user, host;

如果只是排查某个应用账号，可以缩小范围：

SELECT user, host, plugin
FROM mysql.user
WHERE user = 'app_user';

MySQL 8.0的caching_sha2_password为什么还涉及TLS或RSA

caching_sha2_password有快速认证和完整认证过程。服务器已经缓存相应认证信息时，后续连接可以较快完成；需要执行完整认证时，密码交换必须得到适当保护。

官方文档指出，使用caching_sha2_password的客户端应通过安全传输连接，或者在未加密连接上使用RSA密钥交换机制保护密码。 :contentReference[oaicite:7]{index=7}

因此，如果一个驱动已经认识caching_sha2_password，但仍然在远程连接阶段报错，还应该继续检查：

• 数据库连接是否启用了TLS；
• 客户端是否支持相应RSA公钥获取或密钥交换方式；
• 连接字符串是否关闭了本来应该启用的安全连接；
• 数据库中匹配到的到底是哪一个user@host账号。

这类问题与单纯的“用户名密码错误”不是同一个层面。

实际安装时建议怎样选择

如果是维护已经稳定运行的5.7旧系统，短期重点通常是保持应用兼容性、做好备份，并制定升级计划，而不是为了改变认证插件单独重装数据库。

如果准备把5.7迁移到8.0，建议先盘点所有连接数据库的组件，包括网站程序、定时任务、Java服务、Python脚本、备份程序和数据库管理工具。只检查主网站是否能连接是不够的，因为其他后台程序也可能使用较旧的客户端库。

如果是全新的8.0环境，则更合适的做法是保留caching_sha2_password，并选择支持它的现代驱动。为了适配一个旧工具而把整个服务器退回旧认证方案，通常会把兼容问题延后，而不是解决。

一个完整的安装后验证流程

无论安装的是5.7还是8.0，都可以把下面几步作为安装后的固定检查过程。

确认服务状态

systemctl status mysql

需要确认服务处于运行状态。如果系统没有使用systemd，则应使用对应操作系统的服务管理方式。

确认实际版本

mysql --version

不要只依赖软件包文件名，重点查看输出中的主版本号到底是5.7还是8.0。

登录服务器

mysql -u root -p

如果安装包配置了Socket类的本地管理员认证，则实际登录方式可能不同，应按照安装过程中设置的root认证方式处理。

查看服务器与账号认证情况

SELECT VERSION();

SHOW VARIABLES LIKE 'default_authentication_plugin';

SELECT user, host, plugin
FROM mysql.user
ORDER BY user, host;

执行完这几条语句后，应该能够回答三个问题：

• 服务器到底运行的是哪个MySQL版本；
• 服务器创建新账号时默认使用什么认证插件；
• 当前每一个实际账号使用的认证插件是什么。

使用应用程序所用的真实驱动进行连接测试

命令行客户端能连接，只能说明MySQL命令行客户端正常。网站真正使用PHP PDO、JDBC、Python Connector或Node.js驱动时，还应该从应用运行环境进行一次连接测试。

例如，升级到8.0后如果MySQL命令行可以正常连接，但网站报认证插件错误，就没有必要继续反复修改数据库密码。此时更应该检查网站运行环境中的数据库驱动。

安装和迁移时容易出现的几个误区

误区一：MySQL 8.0上的所有账号都是caching_sha2_password

并不是。8.0只是把它作为默认认证插件。旧版本升级过来的账号、明确指定其他插件创建的账号，以及安装包特殊配置的管理账号，都可能使用其他认证方式。

误区二：修改服务器默认插件会自动修改已有账号

服务器默认插件主要影响后续创建账号时的默认选择，不能用它代替对现有账号的检查。现有账号使用什么插件，应查看mysql.user.plugin并根据需要执行ALTER USER。

误区三：8.0连接失败就应该退回mysql_native_password

如果问题只是客户端驱动过旧，升级驱动通常更加合理。将账号降到旧认证方式虽然可能暂时恢复连接，却会继续保留旧客户端依赖。

误区四：安装命令相同，安装出来的版本就一定相同

apt install mysql-server、dnf install mysql-community-server这类命令最终安装哪个版本，取决于已经启用的软件仓库和版本频道。执行命令之前要确认仓库配置，安装之后再检查mysql --version。

总结

MySQL 5.7与8.0在安装操作上的总体思路相似，但实际部署时最需要关注的是版本来源和默认认证方式已经发生变化。MySQL 5.7默认使用mysql_native_password，而MySQL 8.0从8.0.4开始默认使用caching_sha2_password。后者采用SHA-256相关认证机制，也要求客户端具备相应插件支持。

维护5.7旧系统时，重点是确认现有应用依赖并规划升级；安装或迁移到8.0时，则应该优先升级客户端驱动，而不是为了兼容旧程序直接把全部账号改回mysql_native_password。

真正可靠的验证方法也很简单：安装完成后依次检查mysql --version、服务器认证默认值以及mysql.user.plugin。这三项结果结合起来，才能准确判断当前服务器到底运行什么版本、创建新用户会采用什么认证方式，以及具体应用账号实际上使用什么认证插件。