直接 revoke DROP 权限常失效，因 MySQL 中 TRUNCATE、ALTER TABLE DROP COLUMN/PARTITION、CREATE TABLE ... SELECT 等操作可绕过；需同步收回 TRUNCATE（8.0+）、ALTER、CREATE 及 GRANT OPTION 权限，并刷新权限缓存。
直接 revoke DROP 权限为什么经常失效
只执行 REVOKE DROP ON db_name.* FROM 'user'@'host'; 看似合理，但实际常被绕过。根本原因是 MySQL 的权限模型里，DROP 不是删除表的唯一入口：用户即使没 DROP 权限，仍可能用 TRUNCATE TABLE 清空数据（旧版依赖 DROP 权限，MySQL 8.0+ 单独有 TRUNCATE 权限）、用 ALTER TABLE ... DROP PARTITION 或 DROP COLUMN 破坏结构、甚至用 CREATE TABLE ... SELECT 覆盖原表（若 sql_mode 允许且有 CREATE 权限）。更隐蔽的是，权限变更后若不执行 FLUSH PRIVILEGES;，尤其在 MySQL 5.7 及更早版本中，新权限不会生效。
真正起效的权限组合必须覆盖三类操作
防误删不能只盯 DROP TABLE，得同时堵住 TRUNCATE、结构性 ALTER 和覆盖式 CREATE。实操上要分层收回：
-
REVOKE DROP, TRUNCATE ON important_db.* FROM 'dev'@'%';—— 注意 MySQL 8.0+ 才支持单独TRUNCATE权限，低版本需靠DROP控制，但效果不稳 -
REVOKE ALTER ON important_db.* FROM 'dev'@'%';—— 阻止DROP COLUMN、DROP PARTITION等破坏性变更 -
REVOKE CREATE ON important_db.* FROM 'dev'@'%';—— 防止新建同名表覆盖原表，这是最容易被忽略的绕过点 - 检查并收回
GRANT OPTION：REVOKE GRANT OPTION ON *.* FROM 'user'@'host';，否则用户可授权他人间接获得高危权限
权限回收后仍能删表？先查这三处
权限设了却拦不住，大概率是以下情况之一：
- 用户属于某个角色（
ROLE），而REVOKE只清除了直接授予的权限，未切断角色继承链；查SELECT * FROM mysql.role_edges WHERE TO_HOST = 'user'@'host'; - 使用代理用户（proxy user）登录，实际生效的是被代理账号的权限，而非登录账号本身
- 权限缓存未刷新：
FLUSH PRIVILEGES;必须执行，且某些客户端（如 Navicat）会复用连接，需断开重连验证SELECT @@sql_safe_updates;和SHOW GRANTS;
比权限更可靠的其实是“不让它走到执行那步”
权限是底线，但人手抖、复制错、脚本漏参数，这些都不是权限能拦住的。真正降低风险的操作习惯包括：
- 所有生产环境 DELETE/UPDATE 前强制加
SELECT COUNT(*)和SELECT * LIMIT 5，把 WHERE 条件单独保存为变量或注释，避免粘贴时多删一个空格 - DBA 账号禁用密码直连，必须通过跳板机 + OTP 登录，且每次执行高危语句前需输入带时间戳的确认码（如
/* confirm-20260615-1023 */） - 关键库全局开启
read_only = ON，仅给 DBA 账号SUPER或SYSTEM_VARIABLES_ADMIN权限用于临时关闭——这个开关比任何单条权限都硬
权限设置只是第一道门，真正防住误操作的，是让删表这件事从“随手就敲”变成“得动三步才够得着”。
