MySQL 权限错误通常不是“权限被删了”这么简单，而是
mysql系统库中的权限表（如
user、
db、
tables_priv）数据损坏、格式不一致，或
FLUSH PRIVILEGES未生效导致的缓存与磁盘状态脱节。
权限错误常见现象与快速定位
典型报错如：
Access denied for user 'xxx'@'%' to database 'yyy'，但确认
SHOW GRANTS FOR 'xxx'@'%'显示权限存在；或新建用户后始终无法登录，
SELECT * FROM mysql.user却查不到该行——这往往说明权限表结构异常或 MySQL 未加载最新数据。 先检查 MySQL 是否以
--skip-grant-tables启动过，这类启动方式会绕过权限系统，重启后若未正常加载权限表，会导致后续所有权限操作失效 运行
SELECT VERSION(), @@skip_grant_tables;，确认当前是否处于跳过权限模式 用
mysqld --validate-config检查配置合法性，排除
my.cnf中误配
skip-grant-tables或权限相关参数
修复权限表前必须做的三件事
直接修改
mysql库下的表风险极高，务必前置验证和备份： 停止应用连接，避免修复过程中出现并发写入冲突 执行
mysqldump --single-transaction --databases mysql > mysql_backup.sql备份整个系统库（注意：不要只导出
user表，权限依赖多表关联） 确认 MySQL 版本与数据目录中
mysql库的物理文件版本兼容（例如 MySQL 8.0 的
user表含
password_history字段，5.7 直接拷贝会报错）
重建权限表的实操步骤（适用于严重损坏）
当
mysql_upgrade报错、
user表字段缺失或主键损坏时，需手动重建。核心是用官方初始化脚本重刷权限表结构与默认数据，而非直接 INSERT。
以下操作需在 MySQL 停止状态下进行：
cd /usr/local/mysql # 替换为你的 MySQL 安装路径 bin/mysqld --initialize-insecure --user=mysql --datadir=/var/lib/mysql
⚠️ 注意：
--initialize-insecure仅重置
mysql库结构与 root 密码为空，不会清空业务库。执行后必须立刻启动 MySQL 并重设 root 密码：
bin/mysqld_safe --user=mysql & mysql -u root -p # 密码为空，直接回车 ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_secure_password';
再用
CREATE USER和
GRANT重建业务账号，切勿从旧备份中直接
INSERT INTO mysql.user—— 字段顺序、加密方式（
authentication_stringvs
password）、plugin 值都可能不兼容。
权限不生效的隐藏原因：host 匹配与大小写敏感
即使
SELECT * FROM mysql.user WHERE User='app'返回结果，也可能因
Host字段值不匹配而拒绝连接。MySQL 权限匹配按
Host列最长匹配优先，且严格区分大小写（Linux 文件系统下
mysql库名小写，但
Host值本身是字符串匹配）。
'app'@'192.168.1.%'不等价于
'app'@'192.168.1.100'，后者更精确，优先级更高
'app'@'localhost'和
'app'@'127.0.0.1'是两个完全独立的账号，Unix socket 连接走前者，TCP 连接走后者 若应用通过代理或容器连接，
Host值可能是容器名或网关 IP，需用
SELECT USER(), CURRENT_USER();确认实际匹配到的账号
修复时最容易被忽略的是：改完
mysql.user后忘记执行
FLUSH PRIVILEGES;，或者在 MySQL 8.0+ 中误以为
CREATE USER自动刷新——其实只要没显式执行该命令，内存缓存就不会更新。
