不能靠phpMyAdmin修复损坏的mysql.user表——必须用命令行+系统账户通过--skip-grant-tables跳过权限验证后，据MySQL版本选择REPAIR TABLE（5.7及以前）或mysqld --initialize重建（8.0+），再重置密码并FLUSH PRIVILEGES。
不能靠 phpMyAdmin 修复损坏的 mysql.user 表——它本身依赖该表鉴权和查询，必须用命令行 + 系统账户绕过权限检查恢复。
为什么 phpMyAdmin 用户管理页打不开就说明 mysql.user 出问题了
phpMyAdmin 的「用户账户」页面底层执行的是 SELECT * FROM mysql.user。如果该表结构损坏（如 .frm 文件不匹配）、数据页崩溃，或关键字段（如 plugin、authentication_string）值非法，MySQL 可能允许连接但拒绝返回结果，导致页面空白或报错 #1932 / #1033。此时 phpMyAdmin 已失去操作能力，所有图形界面操作都失效。
用 mysqld_safe --skip-grant-tables 启动跳过权限验证
这是唯一能绕过 mysql.user 表读取失败的方法，适用于 MySQL 5.7 及以下；MySQL 8.0+ 改用 --skip-grant-tables 配合 --shared-memory（Windows）或停服后加参数重启。
- 停 MySQL 服务：
sudo systemctl stop mysql（Linux）或net stop mysql（Windows） - 启动跳过模式：
sudo mysqld_safe --skip-grant-tables --skip-networking &（5.7 及以前）；8.0+ 建议改用mysqld --skip-grant-tables --user=mysql并确保无其他实例冲突 - 此时可无密码登录：
mysql -u root，且能执行元数据操作（即使表损坏，INFORMATION_SCHEMA仍可读）
检查并重建 mysql.user 表结构
不要盲目 DROP TABLE——MySQL 8.0+ 的 mysql.user 是只读数据字典视图，物理表已不存在；5.7 及以前才是真实 MyISAM/InnoDB 表。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
立即学习“PHP免费学习笔记（深入）”；
- 先确认版本：
SELECT VERSION(); - MySQL 5.7 及更早：
REPAIR TABLE mysql.user;（仅对 MyISAM 有效）；若失败，退出跳过模式后运行mysql_upgrade -u root --force - MySQL 8.0+：
mysql.user是视图，损坏通常意味着数据字典异常。必须用mysqld --initialize生成新数据目录，或从同版本干净实例导出CREATE TABLE语句手工重建（仅限 5.7） - 通用兜底法（5.7）：从同版本未损坏实例导出建表语句，确保字段顺序、默认值、注释完全一致，再
DROP+CREATE
恢复后必须立刻重置 root 密码并关闭跳过模式
在 --skip-grant-tables 下执行的任何密码修改（如 UPDATE mysql.user SET authentication_string = PASSWORD('xxx') WHERE User='root'）不会立即生效，且存在安全风险。
- MySQL 5.7：
FLUSH PRIVILEGES;后执行ALTER USER 'root'@'localhost' IDENTIFIED BY 'newpass'; - MySQL 8.0+：
ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'newpass';（注意插件名） - 退出跳过模式：杀掉
mysqld进程，正常重启服务：sudo systemctl start mysql - 验证：
mysql -u root -p能否登录；phpMyAdmin 用户页是否可打开
最易被忽略的是：MySQL 8.0+ 中 mysql.user 不是普通表，强行当 MyISAM 修复会彻底破坏数据字典；而跳过模式下未执行 FLUSH PRIVILEGES 或未正确指定认证插件，会导致密码看似修改成功实则无效。
