MySQL 8.0撤销全局管理员权限需分两层：先逐个REVOKE角色绑定，再REVOKE ALL PRIVILEGES和GRANT OPTION ON .，并单独撤销高阶动态权限；撤销后用户仅剩USAGE权限，须重连验证，不可用REVOKE ALL FROM语法。
MySQL 8.0 没有“用户组”概念，也没有“全局管理员角色”这种内置角色；所谓“全局管理员”，通常指被授予了 ALL PRIVILEGES ON *.* 和 GRANT OPTION 的用户，或绑定了高权限自定义角色（如 'dba'）的用户。撤销必须分两层处理：先解绑角色，再清空直接授予的全局权限。
查清用户实际拥有的权限来源
用户看似有“全局管理员权限”，可能来自三种渠道：直接授予的全局权限、绑定的角色、或隐式继承（如 root 用户）。不能只看 SHOW GRANTS FOR 'user'@'host' 的输出，它不展开角色内容。
- 运行
SELECT * FROM mysql.role_edges WHERE TO_USER = 'user' AND TO_HOST = 'host'查该用户绑定了哪些角色 - 运行
SHOW GRANTS FOR 'user'@'host'查直接授予的权限（不含角色） - 检查是否为
root或拥有SYSTEM_VARIABLES_ADMIN、BACKUP_ADMIN等高阶管理权限——这些不包含在ALL PRIVILEGES中，需单独REVOKE
逐个撤销角色绑定（不是“批量解绑”）
MySQL 8.0 不支持 REVOKE ALL FROM 'user'@'host' 或类似语法。角色绑定是显式边关系，必须精准匹配。
- 对上一步查出的每一行
FROM_USER值（即角色名），执行：REVOKE 'role_name' FROM 'user'@'host'（注意单引号包裹，且大小写、下划线、host 全部严格一致） - 若用户有多个 host 变体（如
'user'@'192.168.%'和'user'@'%'），必须分别处理，不能用通配符代替 - 撤销后，用户不会丢失连接能力——
USAGE ON *.*仍存在，仅表示“允许登录”，需额外处理才能禁连
清空直接授予的全局权限
角色解绑只影响角色带来的权限，不影响用户自己被直接授予的 ALL PRIVILEGES ON *.* 或 GRANT OPTION。
- 执行：
REVOKE ALL PRIVILEGES ON *.* FROM 'user'@'host' - 必须额外执行：
REVOKE GRANT OPTION ON *.* FROM 'user'@'host'（否则用户仍可给自己加权） - 如有高阶管理权限（如
SHUTDOWN、SUPER、BACKUP_ADMIN），需逐条REVOKE，例如：REVOKE BACKUP_ADMIN ON *.* FROM 'user'@'host' - 执行完后建议运行
FLUSH PRIVILEGES，避免权限缓存未更新（尤其在连接复用场景下）
验证与收尾：别忽略 USAGE 和会话残留
撤销完成后，用户仍能连上 MySQL，但所有 DML/DQL/DDL 操作都会报 ERROR 1044 (42000) 或 ERROR 1227 (42000) ——这不是失败，而是预期状态。
- 用
SELECT USER(), CURRENT_USER()确认当前会话匹配的账号，避免因 host 匹配偏差误判 - 已建立的连接不会自动丢弃权限，必须重连或新开客户端验证
- 如果目标是彻底禁用该账号登录，需追加：
REVOKE USAGE ON *.* FROM 'user'@'host'（注意必须带ON *.*，否则语法错误） - 不要混淆
DROP ROLE和REVOKE ... FROM：前者删角色定义，后者只解绑；跳过解绑直接DROP ROLE会报错ERROR 3530 (HY000)
