撤销grant option不影响其他已授予权限，真正高危的是super等动态特权；mysql 8.0+已废弃super，需用system_variables_admin等细粒度权限替代，并逐个revoke。
撤销 grant 权限时为什么用户还能执行管理员操作？
因为 mysql 的权限是分层叠加的，grant option 本身不是“管理员权限”，而是“授予权限的权限”；真正让用户拥有高危能力的是 super、system_variables_admin、replication_slave_admin 等动态特权。只执行 revoke grant option 不会影响已授予的其他权限。
实操建议：
- 先查清用户实际持有的高危权限：
SHOW GRANTS FOR 'user'@'host'; -
GRANT OPTION必须和具体权限一起回收，例如：REVOKE INSERT ON db.* FROM 'user'@'host'; REVOKE GRANT OPTION ON db.* FROM 'user'@'host'; - MySQL 8.0+ 中，
SUPER已被拆分为多个细粒度特权，直接REVOKE SUPER会报错（除非兼容模式开启），应改用REVOKE SYSTEM_VARIABLES_ADMIN, SET_USER_ID, ...
回收 SUPER 权限在 MySQL 8.0+ 报错 ERROR 3715 (HY000): The SUPER privilege is obsolete
这是 MySQL 8.0 默认禁用 SUPER 的明确信号——它不再是有效权限名，强行使用会被拒绝。
实操建议：
- 确认 MySQL 版本：
SELECT VERSION();，若 ≥ 8.0.16，SUPER已完全移除语义 - 用
SHOW PRIVILEGES;查当前支持的动态权限列表 - 常见替代权限包括：
SYSTEM_VARIABLES_ADMIN（改全局变量）、SET_USER_ID（模拟用户）、REPLICATION_APPLIER（启动复制）等，需逐个REVOKE - 不要依赖
FLUSH PRIVILEGES：动态权限变更立即生效，该命令仅对 grant 表手动修改有效
回收权限后用户仍能连接并执行 DROP DATABASE？
说明权限未真正清除，最常见原因是权限缓存或 host 匹配不精确。
实操建议：
- 检查是否遗漏了不同 host 的同名用户：
SELECT User, Host FROM mysql.user WHERE User = 'user';，权限按User@Host元组独立存储 - 确认回收操作作用于正确 host：
REVOKE DROP ON *.* FROM 'user'@'192.168.%';不影响'user'@'localhost' - 权限回收后无需重启，但客户端可能复用旧连接；建议让用户断开重连，或服务端执行
KILL对应线程（SHOW PROCESSLIST;查 ID） - 避免用通配符
'user'@'%'授予过高权限，生产环境优先绑定具体 IP 或域名
用 DROP USER 能否彻底清理权限？
可以，但代价是连账号一起删除，且无法选择性保留普通权限——这是“剥夺管理员权限”的过度操作。
实操建议：
-
DROP USER 'user'@'host';会自动清除所有相关权限记录，适合彻底弃用账号 - 如果只是降权，优先走
REVOKE+ALTER USER ... REQUIRE NONE（禁用证书/SSL 要求）组合 - 注意：MySQL 5.7 及以前版本中，
DROP USER不会自动删掉mysql.db表中的数据库级权限，需手动清理（8.0+ 已修复） - 回收完成后，务必用目标用户重新登录验证，别只信
SHOW GRANTS输出
权限回收不是一锤子买卖，关键在于匹配到真实的 User@Host、看清 MySQL 版本对特权模型的改动、以及验证时用实际操作而非仅看元数据。最容易被忽略的是多 host 同名用户和连接复用导致的“权限还在生效”假象。
