REVOKE DROP必须严格匹配GRANT的ON范围，如GRANT DROP ON mydb.users TO 'u'@'%'才可用REVOKE DROP ON mydb.users FROM 'u'@'%';大小写、反引号、host均需完全一致，否则静默失败或报ERROR 1141；单撤DROP不足以防删表，须同步REVOKE ALTER、CREATE、TRUNCATE（8.0+）或DELETE（5.7-），并验证新连接生效。
REVOKE DROP必须严格匹配GRANT的ON范围
MySQL不会自动推断你要撤哪一层权限，REVOKE DROP ON mydb.users FROM 'u'@'%' 只有在当初就是用完全相同的 GRANT DROP ON mydb.users TO 'u'@'%' 授的，才会真正生效。写成 REVOKE DROP ON mydb.* 或 REVOKE DROP ON *.* 都会静默失败或报 ERROR 1141。
常见错配点：
- 大小写不一致：当
lower_case_table_names = 0时，MyDB.Users≠mydb.users - 反引号缺失：表名含横线、点等特殊字符时，
REVOKE DROP ON `my-db`.`log_table` FROM 'u'@'%'才合法，漏掉反引号直接报错 - host 不匹配：'u'@'localhost' 和 'u'@'%' 是两个独立账号，漏撤一个等于白干
单撤DROP防不住删表，必须组合回收
用户即使没有 DROP 权限，只要还有 ALTER 和 CREATE，就能通过 ALTER TABLE t RENAME TO t_bak + CREATE TABLE t 实现逻辑删表。这种绕过在真实生产环境反复出现过。
真正要防误删，得一并回收：
REVOKE DROP, ALTER, CREATE ON mydb.users FROM 'u'@'%'- MySQL 8.0+ 还要加
REVOKE TRUNCATE ON mydb.users FROM 'u'@'%'（5.7 及更早需同步DELETE） - 检查是否残留
SUPER或SYSTEM_VARIABLES_ADMIN：这类权限可关sql_log_bin绕过所有 DDL 约束，REVOKE DROP对其完全无效
撤销后权限不立即生效，验证方式很关键
执行 REVOKE 成功只更新服务端权限表，已建立的连接（包括连接池里的长连接）仍用原权限快照。不能只看 “Query OK” 就认为完事了。
验证是否真生效，必须做两件事：
- 立刻运行
SHOW GRANTS FOR 'u'@'%'，确认输出里已无对应DROP行 - 用新连接测试：
mysql -u u -h db-host -p -e "DROP TABLE mydb.users"，应报错ERROR 1142
生产环境务必通知应用滚动重启连接池，或等连接超时驱逐——这点最容易被跳过，结果权限“看起来撤了”，实则形同虚设。
