truncate不是独立权限，执行它必须拥有对应表的drop权限，因其实现本质是“删表重建”；授予drop on table table_name即可启用truncate，且show grants仅显示drop而非truncate。
TRUNCATE 不是独立权限，它在 MySQL 中实际依赖 DROP 权限——因为内部实现为「删表重建」。所以直接授 TRUNCATE 权限，本质就是授 DROP 权限。但你可以把 DROP 限定到单张表，从而达成「仅能 TRUNCATE 这一张表」的效果。
GRANT DROP ON TABLE 是唯一可靠方式
MySQL 不支持 GRANT TRUNCATE ON ...（会报 ERROR 1064），也不支持 GRANT DROP ON database.* 这种宽泛授权——那等于允许删整个库的任意表。必须精确到表级：
GRANT DROP ON TABLE sales_db.orders TO 'cleaner'@'10.0.2.%';- 这条命令同时赋予
TRUNCATE TABLE sales_db.orders和DROP TABLE sales_db.orders能力 - 用户无法对
sales_db.customers或其他任何表执行TRUNCATE，哪怕有同库其他表的SELECT权限 - 执行后必须
FLUSH PRIVILEGES;，否则权限不生效（服务端缓存权限）
为什么 SHOW GRANTS 看不到 TRUNCATE 字样
运行 SHOW GRANTS FOR 'cleaner'@'10.0.2.%'; 返回的只会是 DROP，不会出现 TRUNCATE ——这是正常现象。MySQL 权限系统里没有 TRUNCATE 这个权限名，它只是 DROP 的副作用。别被表象误导，只要 DROP ON TABLE 存在，TRUNCATE 就可用。
替代方案：用存储过程封装（适合不能给 DROP 的场景）
如果安全策略绝对禁止授予 DROP（哪怕只对一张表），只能走间接路径：
- 用高权限用户（如
admin）创建一个带DEFINER的存储过程：CREATE DEFINER='admin'@'localhost' PROCEDURE sales_db.truncate_orders() MODIFIES SQL DATA BEGIN TRUNCATE TABLE sales_db.orders; END; - 再授执行权：
GRANT EXECUTE ON PROCEDURE sales_db.truncate_orders TO 'cleaner'@'10.0.2.%'; - 用户只能
CALL sales_db.truncate_orders();，无法绕过逻辑或操作其他表 - 缺点：每次新增可清空表都要手动加新过程，运维成本上升
真正容易被忽略的是权限缓存和作用域粒度——DROP ON TABLE 看似宽松，实则是目前 MySQL 唯一能精准控制单表 TRUNCATE 的机制；而忘记 FLUSH PRIVILEGES 或误授 DROP ON sales_db.*，都会导致权限失控。
