必须严格匹配GRANT时的作用域，如GRANT DROP TABLE ON app_db.需用REVOKE DROP TABLE ON app_db.；作用域不一致则静默失败，旧连接权限仍有效，须重连或KILL CONNECTION验证。
REVOKE DROP TABLE 权限必须匹配 GRANT 时的作用域
MySQL 的权限回收不是“覆盖式”操作，REVOKE 只会移除当初用完全相同作用域（db_name.* 或 *.*）授予的权限。比如用户是用 GRANT DROP TABLE ON app_db.* TO 'dev'@'%' 授的权，那必须用 REVOKE DROP TABLE ON app_db.* FROM 'dev'@'%' 才能生效；若误写成 ON *.*，命令执行成功但实际没撤掉。
常见错误现象：执行完 REVOKE DROP TABLE ON *.* FROM 'dev'@'%' 后，仍能成功执行 DROP TABLE app_db.users——本质是权限没真正回收。
- 先确认原始授权范围：
SHOW GRANTS FOR 'dev'@'%'，重点看输出里ON后面的数据库/表范围 - 作用域不一致时，
REVOKE不报错也不起效，属于静默失败 - 若用户有多个作用域的同名权限（如同时有
ON app_db.*和ON *.*），需分别REVOKE
仅撤 DROP TABLE 不足以防误删，TRUNCATE 和 DELETE 也得同步处理
DROP TABLE 是删结构，TRUNCATE TABLE 和无条件 DELETE 是清空数据——三者破坏性不同，但都属高危操作，且权限彼此独立。只撤 DROP TABLE，用户仍可用 TRUNCATE 瞬间清空整表（还不走 binlog），或用 DELETE FROM users 搞定全表删除。
实操建议一次性清理所有相关权限：
- 执行：
REVOKE DROP TABLE, TRUNCATE, DELETE ON app_db.* FROM 'dev'@'%' - 注意：
TRUNCATE权限在 MySQL 中归类为 DDL，需显式回收，不能靠“没授就不具备”来假设 - 若用户有
ALL PRIVILEGES，先REVOKE ALL PRIVILEGES ON app_db.* FROM 'dev'@'%'，再按需重授SELECT, INSERT等安全权限
权限回收后连接不刷新，旧会话仍保留原权限
MySQL 权限变更不会自动同步到已建立的连接。用户只要不退出客户端、不关闭应用连接池里的连接，哪怕你刚执行完 REVOKE，他照样能 DROP TABLE——这是生产环境最常被忽略的点。
关键判断依据不是命令是否返回 Query OK，而是用户当前连接是否已断开：
- 对交互式客户端：让用户退出重连，或自己执行
KILL CONNECTION xxx强制终止其会话 - 对应用连接池（如 HikariCP、Druid）：必须重启服务，或等待连接超时淘汰（通常配置为 30 分钟以上），否则新权限永不落地
- 验证是否真生效：用该账号登录后直接执行
DROP TABLE app_db.test，应报错ERROR 1142 (42000): DROP command denied，而非只看SHOW GRANTS输出
REVOKE 不检查权限是否存在，静默失败风险高
REVOKE 命令本身不校验目标用户是否真的拥有你要撤的权限。例如用户根本没被授过 TRUNCATE，你仍可执行 REVOKE TRUNCATE ON app_db.* FROM 'dev'@'%'，它返回 Query OK，但什么都没做。
这意味着：你以为收掉了，其实可能从头就没授过，或者早被别人用 GRANT OPTION 间接转授了其他权限。
- 务必搭配
SHOW GRANTS FOR 'dev'@'%'验证输出中是否已剔除对应权限项 - 若用户有
GRANT OPTION，要额外执行REVOKE GRANT OPTION ON app_db.* FROM 'dev'@'%'，否则他可能自行再授出去 - MySQL 8.0+ 使用角色时，还要查
mysql.role_edges表，确认没通过角色继承获得DROP权限
真正卡住误删的，从来不是“有没有执行 REVOKE”，而是权限改了之后，那个正在跑着的连接有没有断、那个连着的 Java 应用有没有重启、那个还在执行定时任务的脚本有没有换账号——这些细节比语法本身更决定成败。
