直接不授予drop权限即可，这是唯一可靠且原生支持的方式；revoke drop on db.* from 'u'@'h'后必须执行flush privileges，因truncate table复用drop权限，故一并被禁止，且需注意角色继承与全局权限遗漏。
直接不授予 DROP 权限即可，这是唯一可靠且原生支持的方式；任何试图用触发器、SQL拦截或配置项（如 skip-grant-tables）禁用 DROP TABLE 的做法，要么无效，要么破坏整个权限体系。
为什么只靠 REVOKE DROP 就够了
MySQL 权限是显式授权制：没给就真不能执行。只要用户没有被授予 DROP 权限，哪怕他有 CREATE、ALTER 甚至 SELECT，执行 DROP TABLE 时都会报错：ERROR 1142 (42000): DROP command denied to user。
-
DROP权限作用于库级（ON db_name.*）或全局（ON *.*），不是表级——但对单表的DROP TABLE操作，检查的就是该用户在对应数据库上是否有DROP权限 - 如果之前用
GRANT ALL ON mydb.* TO 'u'@'h'授过权，必须先REVOKE DROP ON mydb.* FROM 'u'@'h'，再FLUSH PRIVILEGES -
SHOW GRANTS FOR 'u'@'h'能看到当前生效权限，但注意：它不反映缓存状态，连接未重连前旧权限可能仍有效
TRUNCATE TABLE 会一并被禁止吗
会。MySQL 内部将 TRUNCATE TABLE 实现为「删表 + 重建」，因此它**不依赖独立权限，而是复用 DROP 权限**。只要没 DROP，TRUNCATE TABLE 同样报错：ERROR 1142 (42000): TRUNCATE command denied to user。
- 不需要单独
REVOKETRUNCATE——MySQL 压根没有这个权限名 - ORM 工具（如 Django 的
migrate:fresh、Laravel 的Schema::dropIfExists()）若调用TRUNCATE或DROP，会直接失败，需改用DELETE FROM table（需DELETE权限） - 验证方式：用目标用户登录后执行
TRUNCATE TABLE t1，看是否报错
容易踩的坑：权限看似撤了，但还是能删表
最常见原因是权限缓存未刷新，或者权限来源被忽略。
- 执行
REVOKE DROP ON mydb.* FROM 'u'@'h'后，必须执行FLUSH PRIVILEGES，否则服务端仍用旧缓存 - 如果用户通过角色（ROLE）获得权限，要对角色
REVOKE DROP，再执行SET DEFAULT ROLE刷新绑定，而不是只 revoke 用户本身 - 检查是否误授了全局权限：
GRANT ... ON *.*会让用户对所有库都有DROP能力，必须收紧到具体库名，如ON myapp.* -
mysql系统库权限不要乱给——用户若能改mysql.user表，可自行加回DROP
替代方案：当业务确实需要部分删表能力时
一刀切回收 DROP 会影响 DBA 日常运维（比如重建分区、重命名表）。真要区分场景，得跳出纯权限层。
- 用 MySQL 8.0+ 角色管理：建一个
app_rw角色（不含DROP），再建一个dba_admin角色（含DROP），按需赋角色 - 应用层拦截：在 DAO 或中间件（如 ProxySQL）做 SQL 白名单，拦截含
DROP TABLE、TRUNCATE TABLE的语句——但这只是兜底，不能替代权限控制 - 备份与 binlog 必须开启：
log_bin = ON，误删后靠mysqlbinlog回滚，这才是最后一道防线
权限控制本身不复杂，但容易卡在缓存刷新、角色继承、全局权限遗漏这些细节上；生产环境里，光靠 REVOKE 不够，必须搭配 FLUSH PRIVILEGES 和实测验证。
