撤销DROP权限需严格匹配原始授权范围，否则报错；权限变更服务端立即生效但当前会话不更新，需重连或KILL连接；应优先用TRUNCATE或mysqldump替代DROP操作。
撤销 DROP 权限前，先确认权限来源
mysql 中 drop 权限可能来自多个层级：全局（grant ... on *.*）、库级（grant ... on db_name.*）、甚至角色继承。直接执行 revoke drop on ... 失败，往往是因为你 revoke 的范围比当初 grant 的范围小。
- 用
SHOW GRANTS FOR 'user'@'host'查清当前所有显式授予的权限，特别注意ON *.*和ON `db`.*两类 - 如果用户有
GRANT OPTION，还要检查是否通过角色间接获得DROP—— 角色权限需单独从角色中 revoke - MySQL 8.0+ 不支持对角色 revoke 后自动刷新用户会话权限，用户需重新连接或执行
SET ROLE DEFAULT
REVOKE DROP 必须匹配原始 GRANT 的作用域
权限回收不是“减法”，而是“逆向撤销”——必须和当初授权时的 ON 子句完全一致，否则报错 ERROR 1141 (42000): There is no such grant defined for user ... on host ...。
- 当初是
GRANT DROP ON `sales`.* TO 'alice'@'%'→ 必须写REVOKE DROP ON `sales`.* FROM 'alice'@'%' - 当初是
GRANT DROP ON *.* TO 'bob'@'localhost'→ 不能只写REVOKE DROP ON `test`.*，必须写REVOKE DROP ON *.* - 库名、用户名、host 都区分大小写（尤其在 Linux 系统下），
`Sales`≠`sales`
撤销后立即生效？不完全是
MySQL 的权限变更在服务端立即生效，但**当前连接的会话不会自动更新权限缓存**，用户仍能执行 DROP 直到断开重连。
- 主动踢掉用户连接：
KILL CONNECTION <code>id（查SHOW PROCESSLIST获取 id） - 或让应用层重连；单纯
FLUSH PRIVILEGES对已存在的连接无效 - 如果用户有
CREATE USER或GRANT OPTION，ta 可能自己再把DROP加回去——务必同步检查并收回这些高危权限
用 mysqldump --no-create-info 替代 DROP 场景更安全
很多所谓“需要 DROP 权限”的操作，其实只是开发/运维习惯性删库重建。真要清理数据，DROP 是最粗暴也最危险的方式。
- 导出结构不带数据：
mysqldump --no-data --skip-triggers db_name > schema.sql - 清空表用
TRUNCATE TABLE（比DROP+CREATE快，且只需DELETE权限） - 若必须重建库，可改用低权限账号创建空库，再由高权限账号导入 —— 把
DROP拆离日常操作流
权限回收不是终点，真正难的是厘清谁在什么环节依赖 DROP，以及有没有更细粒度的替代路径。一纸 REVOKE 下去，CI 脚本或迁移工具突然报错，往往就卡在这一步没想透。
