能登录但GRANT报错ERROR 1142，说明Grant_priv字段为'N'或空值，需UPDATE mysql.user设为'Y'并立即FLUSH PRIVILEGES生效，无需重建用户或重启服务。
能登录但 GRANT 报错 ERROR 1142，说明 Grant_priv 字段被设为 'N' 或空值，不是密码或认证问题——直接更新权限字段 + FLUSH PRIVILEGES 就能恢复，不用重建用户、不需重启服务。
root 能登录但执行 GRANT 报错 1142
这是最常见也最容易误判的情况：你输入密码能进 MySQL，SELECT、SHOW DATABASES 都正常，但一运行 GRANT 就报 ERROR 1142 (42000): SELECT command denied to user 'root'@'localhost' for table 'user' 或类似提示。
根本原因是 mysql.user 表里 Grant_priv（以及常连带的 Super_priv）被设成了 'N'，MySQL 认证通过了，但授权开关关了。
- 先确认状态：
SELECT User, Host, Grant_priv, Super_priv FROM mysql.user WHERE User = 'root'; - 如果
Grant_priv是'N'，执行：UPDATE mysql.user SET Grant_priv='Y', Super_priv='Y' WHERE User='root' AND Host IN ('localhost', '%', '127.0.0.1'); -
必须立刻执行：
FLUSH PRIVILEGES;—— 否则内存缓存不更新，后续操作仍失败 - 验证：
SHOW GRANTS FOR 'root'@'localhost';应该能看到GRANT OPTION
root 能登录但连 mysql 库都进不去
报 ERROR 1044（Access denied）或 ERROR 1142 且连 USE mysql; 都失败，说明权限字段大面积为 'N' 或全空，但身份认证仍通。这时你不能靠自己修自己，得用另一个有 GRANT OPTION 的管理员账号救场。
- 用其他管理员账号登录：
mysql -u admin_user -p - 确认 root 记录存在：
SELECT User, Host FROM mysql.user WHERE User = 'root'; - 授最小必要权限（别直接
GRANT ALL）：GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'root'@'localhost' WITH GRANT OPTION; -
漏掉这步就白干：
FLUSH PRIVILEGES;
所有 root 账户完全无法登录（ERROR 1045 / 连接拒绝）
这时已无高权限入口，必须用 --skip-grant-tables 启动 MySQL，但三个地方极容易断链：
- 启动后第一件事不是改密码，而是先
FLUSH PRIVILEGES;—— 否则后续UPDATE或ALTER USER全报错 - MySQL 8.0+ 必须显式设置
plugin和认证方式：UPDATE mysql.user SET plugin='mysql_native_password', authentication_string=PASSWORD('your_new_pass') WHERE User='root' AND Host='localhost';（注意：8.0.4+ 已弃用PASSWORD()，应改用ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx';） -
'root'@'localhost'和'root'@'127.0.0.1'是两个独立账户，更新时要覆盖全部常见 host，否则从 Navicat 或某些客户端连不上
MySQL 8.0+ 误删 root 后不能直接 CREATE USER
因为 CREATE USER 本身受权限系统保护，没凭据就进不了门；安全模式下它还会校验插件兼容性，直接建容易生成无法认证的空壳用户。
稳妥做法是手动插入记录 + 批量开权限字段 + 显式指定插件：
- 先
INSERT INTO mysql.user (Host, User, plugin, authentication_string, account_locked) VALUES ('localhost', 'root', 'mysql_native_password', '', 'N'); - 再批量开权限：
UPDATE mysql.user SET Select_priv='Y', Insert_priv='Y', Update_priv='Y', Delete_priv='Y', Create_priv='Y', Drop_priv='Y', Grant_priv='Y', Super_priv='Y', Create_user_priv='Y' WHERE User='root' AND Host='localhost'; -
必须立刻：
FLUSH PRIVILEGES; - 最后强制重设认证：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password';
整个过程里最容易被忽略的是 FLUSH PRIVILEGES 的时机和次数——它不是可选项，是权限生效的唯一触发点；而 MySQL 8.0 的插件匹配问题，会让修复后的 root 在老客户端里静默失败，连错误都不报全。
