MySQL升级后用户权限通常不会自动丢失，但是否保留取决于升级方式、版本跨度和系统表兼容性；5.7→8.0因权限表结构重构（如Password列移除、认证插件变更）易导致登录失败，需手动调整plugin与authentication_string。
MySQL 升级后用户权限通常不会自动丢失，但是否保留取决于升级方式、版本跨度和系统表兼容性。直接 in-place 升级（如 mysqld --upgrade）一般会保留 mysql.user 等系统表数据；而全新安装 + 数据目录替换或逻辑导入（mysqldump）则可能因系统表结构变更导致权限失效。
MySQL 5.7 → 8.0 权限表结构变化引发权限不可用
MySQL 8.0 彻底重构了权限系统：mysql.user 表移除了 Password 列，改用 authentication_string；默认认证插件从 mysql_native_password 变为 caching_sha2_password。若升级后用户无法登录，大概率是认证插件不匹配或密码字段未正确迁移。
- 升级前检查所有用户的
plugin值：SELECT User, Host, plugin FROM mysql.user; - 升级后对旧用户执行：
ALTER USER 'u'@'h' IDENTIFIED WITH mysql_native_password BY 'pwd';（如需兼容老客户端） -
mysql_upgrade工具在 8.0.16+ 已废弃，改由服务器启动时自动执行系统表校验与更新 —— 必须确保启动时使用--skip-grant-tables以外的正常模式
mysqldump 导出导入时权限未被包含
mysqldump --all-databases 默认不导出 mysql 系统库（出于安全限制），因此权限信息不会进入 dump 文件。即使手动加上 --databases mysql，8.0 的系统表（如 role_edges、default_roles）也可能因版本差异无法直接导入。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 导出权限专用：用
mysqldump --no-data --skip-triggers mysql user db tables_priv columns_priv procs_priv proxies_priv - 导入前确认目标版本支持对应表结构，尤其注意 5.7 的
password字段需映射到 8.0 的authentication_string - 更稳妥做法：升级后用
SELECT CONCAT('CREATE USER ''',User,'''@''',Host,''' IDENTIFIED WITH ',plugin,' AS ''',authentication_string,''';') FROM mysql.user;生成用户语句，再人工调整后执行
docker 或一键包升级后权限“消失”的真实原因
这不是权限丢失，而是容器/安装包初始化逻辑覆盖了原有 mysql 数据目录。例如 Docker 官方镜像启动时若检测到 /var/lib/mysql 为空，会自动运行 mysqld --initialize 生成新 root 密码并跳过已有数据；某些 Linux 发行版的 mysql-server 包升级也会清空配置并重建数据目录。
- 升级前务必备份完整
/var/lib/mysql/mysql/目录（不是只备份 SQL） - Docker 场景下，必须挂载持久化卷并确保启动时不触发初始化流程（如避免传入
MYSQL_ROOT_PASSWORD环境变量） - 检查
error.log中是否有Starting with no password或Initializing database类提示，这是覆盖行为的关键证据
权限迁移最脆弱的环节不在 SQL 层，而在系统表物理结构与初始化流程的耦合上。哪怕语句能跑通，plugin 和 authentication_string 的实际值是否被正确解析，往往要等第一次连接时才暴露问题。
