ERROR 1044 表示当前登录用户缺少 Grant_priv 权限，需用高权限账号（如 root@localhost）执行 UPDATE mysql.user SET Grant_priv='Y' WHERE User='xxx' AND Host='yyy' 并 FLUSH PRIVILEGES 后方可操作全局权限。
phpMyAdmin里点“全局权限”就报1044，说明当前登录用户没Grant_priv
你不是操作错了，而是登录 phpMyAdmin 用的那个 MySQL 用户（比如 root@localhost 或 admin@%）本身缺少 Grant_priv 权限。phpMyAdmin 在后台执行权限变更时，会悄悄调用 GRANT 语句——而只要当前用户没 Grant_priv，MySQL 就直接返回 ERROR 1044，连具体哪条 SQL 都不让你看到。
常见现象包括：
- 点击“用户”页 → 编辑某个用户 → 勾选“全局权限” → 点“执行”后页面弹出
#1044 - Access denied for user 'xxx'@'yyy' to database 'mysql' - 在“用户”页点“添加用户”，填完信息点执行，同样报 1044
- 能正常登录 phpMyAdmin、能查表、能建库，唯独改权限就失败
SELECT user, host, Grant_priv FROM mysql.user 要先跑这句
别急着点“执行”，先用一个已知有高权限的账号（比如 root@localhost）登录 MySQL 命令行或 phpMyAdmin 查询窗口，执行：
SELECT host, user, Grant_priv, Super_priv FROM mysql.user WHERE user = 'your_login_user';
重点看 Grant_priv 列是不是 'Y'。如果显示 'N'，那问题就锁定了——这个用户被创建时没带 WITH GRANT OPTION，后续所有授权动作都会被拦。
立即学习“PHP免费学习笔记（深入）”；
注意几个关键点：
-
host必须完全匹配，'root'@'localhost'和'root'@'%'是两个独立用户，改错一个没用 - 即使
Super_priv = 'Y'，Grant_priv = 'N'也照样报 1044 - phpMyAdmin 的“配置存储”功能（比如书签、关系图）依赖
phpmyadmin用户，如果它权限不足，也会间接触发 1044
UPDATE mysql.user SET Grant_priv='Y' 后必须 FLUSH PRIVILEGES
确认是权限缺失后，用本地可登录的高权限账号（如 root@localhost）执行：
UPDATE mysql.user SET Grant_priv = 'Y', Super_priv = 'Y' WHERE User = 'your_login_user' AND Host = 'exact_host_from_above';<br>FLUSH PRIVILEGES;
这里最容易踩的坑：
- 漏掉
FLUSH PRIVILEGES—— MySQL 不会自动重载内存里的权限缓存，改了表也没用 - WHERE 条件写错 host，比如把
'192.168.1.100'写成'%'，结果更新了别的用户 - 用 Navicat 或其他 GUI 工具执行后没断开重连，工具还在用旧连接上下文，仍会报错
- MySQL 8.0+ 默认启用
caching_sha2_password插件，如果用户认证插件不匹配，UPDATE可能静默失败（建议搭配ALTER USER ... IDENTIFIED WITH mysql_native_password一起用）
生产环境别让 root@% 拥有 Grant_priv
修复完 immediate 问题后，得回头看看权限设计是否合理。允许 root@'%' 拥有 Grant_priv 等同于把整套数据库的钥匙交到公网手里——只要密码泄露或中间人劫持，攻击者就能给自己加权限、导出所有数据。
更稳妥的做法是：
- 禁用或删除
root@'%'，只保留root@localhost用于本地维护 - 新建专用管理账号，例如
dba@'10.0.0.%'，创建时就带WITH GRANT OPTION - phpMyAdmin 自身使用的控制用户（
phpmyadmin）只授其所需最小权限，比如SELECT, INSERT, UPDATEonphpmyadmin.*，不要给GRANT
权限模型里，“能不能进大门”和“能不能给别人发钥匙”是两道独立关卡。1044 报的永远是第一道门——你得先确认自己手里的钥匙真能开门，而不是急着去帮别人配新钥匙。
