必须严格匹配GRANT的作用域才能成功REVOKE DROP权限，仅撤该权限无法防误删，还需同步回收TRUNCATE、DELETE、ALTER、CREATE等权限，并用新连接验证生效。
不能只靠 REVOKE DROP 就防住误删表——它只是起点，不是终点。
REVOKE DROP 必须严格匹配 GRANT 的 ON 子句
MySQL 不会自动推断你要撤哪一层权限。当初用 GRANT DROP ON myapp.users 授的，就必须用 REVOKE DROP ON myapp.users 撤；若当初是 GRANT DROP ON myapp.*，那撤单表就无效，必须先确认原始授权。
-
SHOW GRANTS FOR 'u'@'%'是唯一可靠依据，逐行比对ON后的内容 - 数据库名、表名大小写敏感（
lower_case_table_names = 0时），MyDB.Users≠mydb.users - 含横线、点等特殊字符的表名必须用反引号：
REVOKE DROP ON `my-db`.`log_2026` -
'u'@'localhost'和'u'@'%'是两个独立账号，漏一个，权限照旧
只撤 DROP 权限根本拦不住数据破坏
用户仍可通过其他路径清空或覆盖表结构，仅靠 DROP 收回毫无防护意义。
-
TRUNCATE TABLE在 MySQL 8.0+ 需单独TRUNCATE权限，旧版则依赖DROP+DELETE，所以得同步REVOKE TRUNCATE, DELETE ON myapp.users -
ALTER TABLE ... DROP COLUMN属于ALTER权限范畴，和DROP无关，但能结构性破坏表 - 有
CREATE权限的用户可DROP后立刻重建同名表，效果等同误删 - 持有
SUPER或SYSTEM_VARIABLES_ADMIN的用户，可关sql_log_bin直接执行 DDL，REVOKE DROP对其完全无效
撤销后权限不立即在已有连接中生效
执行 REVOKE 成功只更新服务端权限表，已建立的连接（包括连接池里的长连接）仍用原权限快照。
- 验证是否真生效：必须用新连接测试，例如
mysql -u u -h db-host -p -e "DROP TABLE myapp.users" - 生产环境需通知应用滚动重启连接池，或等连接超时驱逐（通常 30 分钟以上）
- 交互式客户端可手动
KILL CONNECTION xxx强制终止会话 -
FLUSH PRIVILEGES在 MySQL 8.0+ 中非必需，但它会强制重载整张权限表，高并发实例应避开业务高峰执行
真正难的不是写对那条 REVOKE，而是确认用户当前实际持有的权限、所有可能的绕过路径，以及连接状态是否已刷新。漏掉任意一环，所谓“收回”就只是幻觉。
