MySQL 8.0 不允许直接用 GRANT 给 root 授全局权限，因为 root 是系统保留账户，其权限由 mysql.user 表中 Super_priv 等字段硬编码控制，不走常规 GRANT 流程；执行会报 ERROR 1064（语法拒绝），需新建独立账号并显式授权，且 ALL PRIVILEGES 不包含 SYSTEM_USER、REPLICATION CLIENT 等新增管理权限。
MySQL 8.0 为什么不再允许直接用 GRANT 给 root 授全局权限
因为 root 是系统保留账户，它的权限由 mysql.user 表中硬编码字段（如 Super_priv、System_user_priv）控制，不走常规 GRANT 流程。执行 GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' 会直接报错 ERROR 1064 (42000)，这不是权限不足，而是语法被拒绝。
真正需要全局管理权的，应该新建独立账号，比如：
CREATE USER 'dba_admin'@'%' IDENTIFIED BY 'strong_pass'; GRANT ALL PRIVILEGES ON *.* TO 'dba_admin'@'%' WITH GRANT OPTION;
注意：必须显式指定 host（@'%' 和 @'localhost' 完全不同），且不能省略 WITH GRANT OPTION——否则该账号无法再授权给他人。
ALL PRIVILEGES 在 MySQL 8.0 不等于“能干所有事”
ALL PRIVILEGES 只覆盖传统 DML/DCL 类权限（SELECT、INSERT、ALTER、DROP 等），但 MySQL 8.0 新增的动态管理权限默认不包含在内：
-
SYSTEM_USER：用于SET ROLE或切换用户上下文 -
REPLICATION CLIENT：查看主从状态（SHOW SLAVE STATUS） -
BACKUP_ADMIN：执行BACKUP LOCK或物理备份 -
KILL：终止任意线程（替代旧版 SUPER 的一部分功能） -
CLONE_ADMIN：克隆实例（需额外开启 clone plugin）
如果业务需要查主从延迟，只授 ALL PRIVILEGES 是不够的，必须补一句：
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
GRANT REPLICATION CLIENT ON *.* TO 'monitor_user'@'%';
为什么拆出 KILL 权限这种细粒度控制
过去靠 SUPER 实现线程终止，但 SUPER 同时允许修改 innodb_buffer_pool_size、停组复制、甚至绕过密码策略，风险过大。MySQL 8.0 把它拆成独立动态权限后：
- 开发可申请
KILL权限来处理慢查询，无需接触配置项 - DBA 能精确回收，比如
REVOKE KILL ON *.* FROM 'dev_user'@'%' - 该权限不依赖登录态：只要连接用的是已授权账号，就能
KILL其他同账号发起的线程（前提是没开skip-name-resolve导致 host 匹配错乱）
但要注意：KILL 权限只对当前连接生效，不自动继承到角色里——必须显式 GRANT KILL ON *.* TO 'role_name' 才行。
权限不生效？先看 SELECT user(), current_user()
很多“授了权却连不上/查不了”的问题，根源不在权限语句本身，而在匹配逻辑：
-
user()返回客户端声明的用户名+host（可能被 DNS 解析改写） -
current_user()返回 MySQL 实际匹配到的账号（即mysql.user表里存在的那条记录） - 两者不一致，说明 host 写法或
skip-name-resolve配置导致权限表没匹配上
例如你 GRANT 了 'app'@'192.168.1.%'，但 current_user() 返回 'app'@'localhost'，那就说明连接时用了 socket 或解析失败 fallback 到了 localhost，权限自然不生效。
这种细节不会报错，只会静默拒绝，排查时最容易卡住。
