ERROR 1044 是因用户缺少 Grant_priv 权限导致的访问拒绝，需用高权限账号（如 root@localhost）更新 mysql.user 表中对应用户的 Grant_priv 和 Super_priv 为 'Y' 并执行 FLUSH PRIVILEGES 后方可授权。
ERROR 1044 是权限不足，不是密码或网络问题
报 ERROR 1044 (42000): Access denied for user 'root'@'%' to database 'mysql'，说明你当前登录的用户（比如 root@'%'）根本没有操作 mysql 系统库的权限——连 USE mysql 都被拦住，更别说 GRANT 或改用户表了。这不是密码错、没启动、连不上端口的问题，而是 MySQL 权限模型里最底层的“能不能进大门”的限制。
查清楚谁在用、缺什么权限
先用有权限的账号（比如 root@localhost 或 root@127.0.0.1）登录，执行：
SELECT host, user, Grant_priv, Super_priv FROM mysql.user WHERE user = 'root';
重点看 Grant_priv 列：如果对应远程 host（如 '%' 或具体 IP）那一行是 'N'，就确认了问题根源——这个账号被创建时没给 GRANT OPTION，后续所有授权命令都会失败。
-
Grant_priv = 'N'→ 不能执行任何GRANT/REVOKE -
Super_priv = 'N'→ 无法绕过权限检查（比如设skip-grant-tables后仍可能受限） - 哪怕
Super_priv = 'Y'，Grant_priv = 'N'也照样报 1044
修复 Grant_priv 权限（必须用高权限账号操作）
用本地可登录的 root（如 root@localhost）执行：
UPDATE mysql.user SET Grant_priv = 'Y', Super_priv = 'Y' WHERE User = 'root' AND Host = '%';
FLUSH PRIVILEGES;
⚠️ 注意：Host 值必须严格匹配你查出来的值（比如是 '%' 就不能写成 'localhost'），否则更新无效；FLUSH PRIVILEGES 不可省，否则内存缓存不刷新。
之后再试远程授权命令：
GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.168.1.100' IDENTIFIED BY 'your_password' WITH GRANT OPTION;
为什么直接 GRANT ... WITH GRANT OPTION 会失败？
因为 WITH GRANT OPTION 本身就需要当前用户拥有 Grant_priv。就像你没钥匙，却想把锁匠工具借给别人去开别人的门——MySQL 直接拒绝这种“越权授权”。很多教程跳过权限校验步骤，直接让新手跑 GRANT，结果全卡在 1044 上。
真正要远程管理，别只依赖一个 root@'%'：优先建专用管理账号（如 admin@'192.168.1.%'），并确保它从创建起就带 WITH GRANT OPTION；而 root@'%' 这种通配账号，生产环境最好禁用或限制 IP 段，避免权限过大反而失控。
