MySQL 中禁止用户执行
DROP操作，核心是**不授予
DROP权限**，并避免授予高危全局权限（如
ALL PRIVILEGES或
GRANT OPTION）。单纯靠 SQL 语句拦截或触发器无法阻止
DROP，必须从权限体系入手。
只授予必要对象级权限
为业务用户分配权限时，应明确指定数据库、表范围，且**不包含
DROP**： 允许增删改查：用
SELECT, INSERT, UPDATE, DELETE允许建表（如需）：单独加
CREATE，但不加
DROP禁止删库/删表：绝不授予
DROP权限，也不授
ALTER（可重命名/修改表结构，间接风险高）
示例：
GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO 'appuser'@'192.168.%';禁用高危全局权限
以下权限一旦开启，可能绕过常规限制导致误删：
ALL PRIVILEGES（含
DROP）——生产环境严禁直接授予
GRANT OPTION——用户可自行授权，包括给自己加
DROP
PROCESS或
SUPER（MySQL 5.7 及以前）——可能 kill 连接或修改运行参数，间接影响稳定性
检查方法：SHOW GRANTS FOR 'username'@'host';，发现异常权限立即回收。
使用最小权限角色（MySQL 8.0+）
推荐用角色（ROLE）统一管理权限策略，再将角色赋予用户，便于审计和批量调整：
CREATE ROLE 'app_rw';GRANT SELECT, INSERT, UPDATE, DELETE ON prod_db.* TO 'app_rw';
GRANT 'app_rw' TO 'appuser'@'%';
SET DEFAULT ROLE 'app_rw' TO 'appuser'@'%';
后续只需修改角色权限，所有绑定用户自动生效，避免漏配。
补充防护措施（非权限层）
权限控制是主防线，还可叠加以下手段降低误操作风险：
启用sql_log_bin = OFF（仅会话级）不现实，但可配合审核工具拦截高危语句 在中间件（如 ProxySQL、ShardingSphere）或应用 DAO 层做 SQL 白名单/黑名单，拦截
DROP TABLE、
DROP DATABASE定期备份 + binlog 启用（
log_bin），确保误删后可快速恢复 DBA 操作强制走审批流程，生产环境禁用 root 直连，用带审计的跳板机
不复杂但容易忽略。
