REVOKE无法撤销角色权限，必须先查mysql.role_edges绑定角色再显式解绑；部分撤销需启用partial_revokes=ON且不兼容INFORMATION_SCHEMA；USAGE权限需单独撤销才能彻底锁账号。
REVOKE 不能自动清理角色绑定，必须显式解绑
用户权限降权后仍能执行原操作，大概率是因为权限来自角色而非直接授予。MySQL 的 REVOKE ALL PRIVILEGES ON *.* FROM 'user'@'host' 对角色授予的权限完全无效——它只影响显式授出的权限，不触碰 mysql.role_edges 中的角色关系。
要真正剥离权限，分两步走：
- 查绑定角色：
SELECT FROM_USER FROM mysql.role_edges WHERE TO_USER = 'user' AND TO_HOST = 'host'; - 逐个解绑：
REVOKE 'role_name' FROM 'user'@'host';（注意单引号包裹角色名）
别跳过第一步。直接 DROP ROLE 可能误伤其他共用该角色的用户；而漏掉某个角色，就会导致“明明 revoke 了却还有权限”的现象。
部分撤销（PARTIAL REVOKES）不是补丁，是独立权限层
启用 partial_revokes=ON 后，REVOKE SELECT ON sys.* FROM 'user'@'%' 这类语句才生效。但它不修改原有权限，而是叠加一条“例外规则”：用户仍有全局 SELECT，但对 sys 库的查询会被拒绝。
关键限制有三个：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须先运行
SET PERSIST partial_revokes = ON;，否则报错ERROR 3789 (HY000) - 不能对
INFORMATION_SCHEMA或通配库名（如test_%）使用部分撤销 - 一旦用户存在部分撤销，后续执行
REVOKE ALL PRIVILEGES ON *.* FROM ...会失败，报错ERROR 3790 (HY000)，必须先用REVOKE ... ON db.* FROM ...清掉部分规则
USAGE 权限不等于“没权限”，它是隐形连接权
很多降权操作后用户还能连上 MySQL，只是执行 SQL 报错，根源就是 USAGE 没被撤掉。REVOKE ALL PRIVILEGES ON *.* FROM 'user'@'%' 不动 USAGE，它始终存在，直到你显式执行 REVOKE USAGE ON *.* FROM 'user'@'%'。
这条命令的效果是：用户仍能通过认证，但除 PING 和空查询外，任何操作都会返回 Access denied。这是最轻量级的“锁账号”方式，比 DROP USER 更可控，也避免了清理关联权限表的风险。
FLUSH PRIVILEGES 不是万能刷新键
在 MySQL 8.0+ 中，绝大多数 REVOKE 操作是即时生效的，不需要 FLUSH PRIVILEGES。只有当你绕过 SQL 接口、直接 UPDATE mysql.user 等系统表时，才需要它来强制重载缓存。
滥用 FLUSH PRIVILEGES 反而可能掩盖问题：比如你忘了撤角色，又执行了 flush，会误以为“已经生效了”。真实权限状态，应以 SHOW GRANTS FOR 'user'@'host' 输出为准——里面出现 REVOKE SELECT ON `sys`.* FROM ... 才算部分撤销落地，出现空结果集才说明角色和显式权限都清完了。
