MySQL中TRUNCATE权限本质是DROP和CREATE权限的组合，执行TRUNCATE TABLE时内部先DROP再CREATE表；因此无法单独授予TRUNCATE而不赋予DROP和CREATE权限，生产中应改用DELETE+事务、存储过程封装或运维统一入口等安全替代方案。
TRUNCATE权限本质就是DROP+CREATE
MySQL里没有独立的TRUNCATE权限，它实际是DROP和CREATE两个权限的组合。官方文档明确说明：执行TRUNCATE TABLE时，MySQL内部会先DROP原表、再用相同定义CREATE一张新表。所以你看到GRANT TRUNCATE ON db.tbl TO 'u'@'h';能成功，并不是因为存在单独权限，而是MySQL在语法层做了映射，底层仍校验DROP和CREATE权限。
想只给TRUNCATE不给DROP？做不到
这是最常被误解的一点。如果你执行：
GRANT TRUNCATE ON mydb.mytable TO 'app_user'@'10.20.30.%';
等价于：
GRANT DROP, CREATE ON mydb.mytable TO 'app_user'@'10.20.30.%';
这意味着该用户不仅能清空mytable，还能：
- 执行
DROP TABLE mytable（删表） - 执行
CREATE TABLE mytable（重建同名表，可能覆盖结构） - 若同时有
INSERT权限，甚至能反复删-建-插，绕过外键或触发器约束
所以“只给TRUNCATE不给DROP”在MySQL权限模型中是逻辑矛盾——没有DROP，TRUNCATE根本无法工作。
生产环境真正可行的安全替代方案
既然无法拆分TRUNCATE权限，就该放弃这个目标，转而用更可控的方式达成“清空数据”的业务需求：
-
用
DELETE FROM+ 事务 + 条件限制：授予DELETE权限，配合sql_safe_updates=ON防止无WHERE误删；清空前显式BEGIN; DELETE FROM tbl WHERE 1=1; COMMIT;，可回滚、触发器生效、受外键约束保护 -
封装存储过程：创建一个
TRUNCATE_SAFE过程，内部用DELETE或带检查的TRUNCATE，然后只授EXECUTE权限给用户。这样权限收口在过程内，还能加日志、校验、白名单表名等逻辑 - 运维侧统一入口：禁止应用账号直接执行清空操作，改由DBA脚本或自动化平台（如Ansible+SQL模板）完成，所有操作走审批+审计日志
如果真要保留TRUNCATE语义，唯一可控点是把TRUNCATE权限限定到单张表（如GRANT TRUNCATE ON mydb.log_tmp TO 'user'@'%';），并确保这张表不存核心数据、无外键依赖、结构不可变——但依然等于给了DROP和CREATE。
检查你是否无意中放出了高危权限
很多人以为只执行了GRANT TRUNCATE，就只开了清空权限，其实已经悄悄打开了删表能力。验证方式很简单：
SHOW GRANTS FOR 'app_user'@'10.20.30.%';
如果结果里出现DROP或CREATE（哪怕没手动授过），基本就是TRUNCATE授权带进来的。这时候要立刻回收：
REVOKE DROP, CREATE ON mydb.mytable FROM 'app_user'@'10.20.30.%';<br>FLUSH PRIVILEGES;
注意：REVOKE必须针对原始授权范围，不能只写REVOKE TRUNCATE——因为那条权限根本不存在，只是语法糖。
