MySQL权限错误主因是系统库权限表数据损坏、格式不一致或FLUSH PRIVILEGES未生效致缓存与磁盘脱节；需检查--skip-grant-tables模式、备份mysql库、验证版本兼容性，再通过--initialize-insecure重建权限表结构并重设密码。
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_string vs 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 自动刷新——其实只要没显式执行该命令，内存缓存就不会更新。
