宝塔面板中唯一可行的是停服务+原地升级；mysqldump导入必然失败，因utf8mb3隐式转换导致截断、caching_sha2_password认证失败、系统库结构不兼容；必须用mysqlsh检查兼容性、备份数据、升级后调整authentication_plugin和collation配置。
宝塔面板里没有真正“平滑”的 MySQL 5.7 → 8.0 升级路径——所谓停服务+原地升级，才是唯一被验证可行的方式；直接 mysqldump 导入、卸载重装、甚至宝塔点“升级”按钮但跳过检查，90% 会出问题。
为什么 mysqldump 全库导入在 MySQL 8.0 上必然失败
你执行 mysqldump --all-databases 再用 mysql 导入，表面成功，实际踩了三个硬坑：
-
CHARSET=utf8（即 utf8mb3）表在 8.0 中被隐式转成utf8mb4，但字段长度没扩容，插入超长中文直接截断或报错 - 用户认证插件从
mysql_native_password变为caching_sha2_password，PHP 连接时抛出Client does not support authentication protocol -
mysql系统库不能导入：8.0 删除了mysql.plugin表，mysql.user字段重构（如plugin、authentication_string类型变更），导入卡在第 12 张表就中断
宝塔“升级”按钮到底能不能用
能，但有严格前提——它本质是调用官方 mysql_upgrade 做原地二进制替换，不是重装：
- 当前 MySQL 5.7 版本必须 ≥
5.7.26（低于此版本先升到 5.7.26，再升 8.0） - 必须提前停掉所有依赖 MySQL 的服务：
PHP、网站、计划任务、Redis（若启用了 MySQL 监控） - 升级包需匹配系统架构（
x86_64/aarch64）和glibc版本；宝塔提供的 RPM/DEB 包已适配 CentOS/Ubuntu，别手动替换成官网源码编译版 - 必须执行完整备份：
mysqldump -u root -p --all-databases --single-transaction --routines --events > full_backup.sql，并额外打包数据目录：tar -czf /www/backup/mysql_data_$(date +%F).tar.gz /www/server/data
升级后必须立刻改的三处配置
MySQL 8.0 启动成功 ≠ 网站能用。不调整以下三项，第二天就可能集体报错：
- 修改
/etc/my.cnf，在[mysqld]下追加：default_authentication_plugin=mysql_native_passwordcollation-server=utf8mb4_unicode_ci - 重启 MySQL：
service mysqld restart - 重置所有用户密码（包括
root）：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_new_password';
升级前必须做的兼容性检查
别跳过这一步——MySQL 官方 mysqlsh 的 util.checkForServerUpgrade() 函数，会从 28 个维度扫描你的 5.7 实例：
- 下载对应目标版本（如
8.0.34）的mysqlsh，执行：./mysqlsh -uroot -p -S /tmp/mysql.sock --js -e "util.checkForServerUpgrade({'targetVersion':'8.0.34', 'configPath':'/etc/my.cnf'})" > upgrade_check.log - 重点看报告里的
Errors和Warnings：比如GROUP BY不合规 SQL、含 MySQL 8.0 关键字（如ROLE、WINDOW）的表名、MyISAM系统表残留等 - 检查结果有效期仅 24 小时；期间若新增只读实例或灾备实例，需重新检查
最易被忽略的是：升级后 sql_mode 会被重置为 8.0 默认值（含 ONLY_FULL_GROUP_BY），大量旧业务 SQL 会直接报错；还有 JSON_EXTRACT 返回类型变更、TIMESTAMP 自动补时区等行为差异，必须在测试环境跑通全链路再上生产。
