直接用mysqldump导入MySQL 5.6备份到8.0必然失败，因字符集（utf8mb3→utf8mb4）、系统表结构、认证插件（mysql_native_password→caching_sha2_password）等底层不兼容。
直接用 mysqldump 导入 8.0 必然失败
不是操作不对，是底层不兼容。MySQL 5.6 的 mysqldump 输出默认基于 latin1 或 utf8（即 utf8mb3），而 8.0 默认 character_set_server=utf8mb4；更关键的是，5.6 的 mysql 系统库结构、认证插件（mysql_native_password → caching_sha2_password）、authentication_string 字段替代 password 等，全被 8.0 重构过。直接导入会卡在 mysql.plugin 表或 mysql.user 表报错退出，且中文字段大概率乱码。
宝塔面板的「数据库备份」功能不能用于 5.6→8.0
它只是图形化封装了 mysqldump -u root -p --all-databases，本质仍是逻辑导出。所谓“自带无损迁移工具”是常见误读——宝塔从不提供跨大版本的数据迁移能力。你点的那个「恢复」按钮，不会自动转字符集、不会重写认证字段、也不会跳过已删除的系统表。一旦执行，轻则部分库导入中断，重则 root 账户锁死、网站库用户无法连接。
唯一安全路径：原地升级 + mysql_upgrade
必须保留原 /www/server/data 目录，仅替换 MySQL 二进制文件，并由宝塔触发官方 mysql_upgrade 流程。这个过程会：
- 逐个校验并修复
mysql系统库表结构（如 plugin 类型变更、authentication_string字段补全） - 将所有表的默认字符集与排序规则升级为
utf8mb4_0900_ai_ci（若原表未显式指定） - 重置用户认证插件为
caching_sha2_password，并生成新密文 - 检查并警告废弃的
sql_mode（如NO_AUTO_CREATE_USER）
执行前必须确认四点：innodb_fast_shutdown=0 已设置、skip-grant-tables 未启用、my.cnf 中无硬编码 sql_mode 含废弃项、所有分区表引擎已是 InnoDB。
如果真要逻辑迁移，必须人工干预每一步
仅限无法原地升级的极端场景（如换服务器、换操作系统）。需分三阶段手动处理：
- 导出时强制指定编码：
mysqldump --default-character-set=utf8mb4 -u root -p --single-transaction --routines --triggers --events --databases db1 db2 > dump.sql - 导入前清理 dump.sql：删掉所有对
mysql库的CREATE DATABASE和INSERT INTO mysql.*语句；搜索替换ENGINE=MyISAM为ENGINE=InnoDB；删掉含INNODB_前缀的用户表CREATE TABLE（避免与 8.0 系统视图冲突） - 导入后手动重建用户：
CREATE USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY 'pwd'; GRANT ALL ON db1.* TO 'app'@'%'; FLUSH PRIVILEGES;
字符集混用、外键名超长、GROUP BY 非确定性排序这些细节，不会报错但会导致后续 SQL 异常——必须在测试环境用真实业务流量压测验证，不能只看导入成功与否。
