MySQL 8.0升级后mysql.user报错是系统库结构不匹配所致，需停服务后用同版本干净实例导出结构替换损坏的mysql目录；若无干净环境，才可谨慎使用--initialize-insecure并提前完整备份原mysql目录。
MySQL 8.0 升级后连不上，mysql.user 报错不存在或字段缺失
这不是密码问题，是系统库结构不匹配导致的硬性拒绝——升级时没重建 mysql 库，或用了 --skip-grant-tables 启动后误操作清空了权限表。此时 --initialize-insecure 不是首选方案，它会覆盖整个 mysql 系统库，丢掉所有用户、角色、存储过程定义，且无法保留原 root 密码。
真正该做的是：停服务 → 从同版本干净实例导出结构 → 替换损坏的 mysql 目录文件。若手头没有干净环境，再考虑初始化，但必须提前备份原 /var/lib/mysql/mysql/ 目录（含所有 .ibd、.sdi 文件），否则恢复后用户全丢、复制中断、GTID 丢失都可能发生。
用 --initialize-insecure 前必须确认的三件事
这个参数只在 MySQL 完全无法启动、且无可用备份时才兜底使用。执行前务必确认：
-
mysqld进程已彻底停止（ps aux | grep mysqld无残留） - 原
mysql目录已重命名备份，例如：mv /var/lib/mysql/mysql /var/lib/mysql/mysql_bak_20260412 - 配置文件
my.cnf中已注释或删除innodb_force_recovery，否则初始化会失败
执行命令示例：mysqld --initialize-insecure --user=mysql --datadir=/var/lib/mysql。注意：它不会生成随机密码，root@localhost 默认空密码，启动后第一件事就是立刻改密：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_strong_pwd'; FLUSH PRIVILEGES;
mysql_upgrade 已废弃，别再用
MySQL 8.0.16 起官方移除了 mysql_upgrade 工具。升级后如果发现 performance_schema 或 information_schema 视图报错、SHOW GRANTS 返回空、或者 SELECT * FROM mysql.user 提示字段不存在，说明系统表结构未适配新版本。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
正确做法是让 MySQL 在首次启动时自动完成升级：删掉旧 mysql 目录（或替换为同版本结构）→ 启动服务 → 它会自动运行内部升级逻辑，重建视图、填充新字段（如 password_last_changed）、迁移 authentication_string 格式。强行运行已删除的 mysql_upgrade 命令只会报 command not found 或触发不可预知的元数据冲突。
修复后仍无法登录，重点查 plugin 字段
即使 mysql.user 表存在且字段齐全，root 用户仍可能因认证插件不匹配而拒绝连接。连进后立即执行：SELECT user, host, plugin, authentication_string FROM mysql.user WHERE user = 'root';
常见错误组合：
-
plugin = 'auth_socket'但你用密码连接 → 改成mysql_native_password -
authentication_string为空或仍是旧版PASSWORD()加密结果 → 必须用ALTER USER重设密码 -
host = '127.0.0.1'和'localhost'是两个不同账户，别漏改
修改后务必执行 FLUSH PRIVILEGES; —— 这个命令在跳过权限模式下依然生效，但很多人忘了加，导致改完白改。
