阻止用户执行 DROP DATABASE 的唯一可靠方式是直接回收其 DROP 权限，MySQL 不支持拦截或触发器机制；需先 SHOW GRANTS 查权限，再 REVOKE DROP ON db_name.*，并收回 GRANT OPTION。
MySQL 中如何阻止用户执行 DROP DATABASE
直接剥夺权限是唯一可靠方式——mysql 不提供“拦截”或“钩子”机制，所谓“拦截”本质是提前拒绝执行。只要用户拥有 drop 权限，服务器就会执行语句；没有该权限，语句一提交就报错 error 1044 (42000)。
实操上分两步：查清当前权限、精准回收。别用 GRANT ALL 授权后又试图靠应用层过滤 SQL，那纯属掩耳盗铃。
- 先确认目标用户实际拥有的权限：
SHOW GRANTS FOR 'username'@'host';
-
DROP DATABASE权限绑定在数据库级别（不是全局），所以要回收指定库的DROP权限：REVOKE DROP ON `db_name`.* FROM 'username'@'host';
- 如果用户有
GRANT OPTION，务必一并收回，否则他可能自己再授回去 - 执行
FLUSH PRIVILEGES;生效（仅当手动修改了mysql.db表才强制需要；常规REVOKE会自动刷新）
为什么不能靠 sql_mode 或触发器“拦截” DROP DATABASE
DROP DATABASE 是 DDL 操作，不走存储过程、不触发任何触发器，也不受 sql_mode 控制。想用 BEFORE DROP 触发器？MySQL 根本不支持这种语法——它只支持 BEFORE/AFTER INSERT/UPDATE/DELETE。
常见错误思路包括：
- 在应用里正则匹配 SQL 并拦截
DROP关键字 → 绕过方式太多（大小写混写、注释分割、Unicode 空格） - 给用户开
SELECT+INSERT权限，但漏掉显式REVOKE DROP→ 只要之前授过ALL PRIVILEGES，DROP就依然有效 - 以为禁用
root就安全 → 实际上任意有DROP权限的普通用户都能删库
PostgreSQL 用户想拦 DROP DATABASE 怎么办
PostgreSQL 更严格：只有超级用户或数据库所有者才能执行 DROP DATABASE。所以最简单有效的做法是——别把数据库的所有权给业务用户。
- 建库时用超级用户操作：
CREATE DATABASE app_db OWNER app_owner;
- 然后只给业务用户
CONNECT和模式内权限：GRANT CONNECT ON DATABASE app_db TO app_user;<br>GRANT USAGE ON SCHEMA public TO app_user;<br>GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO app_user;
- 业务用户连
\l都看不到其他库，更别说删——因为DROP DATABASE要求你既是所有者又是超级用户（除非用ALTER DATABASE ... OWNER TO把所有权转给他）
误删库后能“拦截”吗？不能，但可以降低风险
真删了就没了，没所谓“运行中拦截”。所谓防护，全是事前控制。
- 生产环境禁用
root远程登录，DBA 用带审批的跳板机操作 - 所有
DROP DATABASE必须走工单系统，由 DBA 手动执行（脚本里加SLEEP 30和人工确认提示） - 定期全量备份 + binlog 增量归档，恢复窗口控制在 5 分钟内——这才是比“拦截”实在得多的兜底
- 监控告警配置关键词：抓取 MySQL general_log 或慢日志里含
DROP DATABASE的行，立刻飞书/钉钉报警
权限回收本身很简单，难的是厘清谁该有什么权限、谁曾经被悄悄授权过、备份是否真能还原。删库不是技术问题，是流程和意识问题。
