TRUNCATE不能靠REVOKE DROP权限禁止，因其依赖DROP+CREATE组合权限；应显式撤销库级DROP和CREATE权限，并仅授予最小必要权限，8.0.23+可直接用TRUNCATE权限。
TRUNCATE 不能靠 REVOKE DROP 权限来禁止
很多人误以为 DROP 权限管着所有“删表”行为，但 TRUNCATE TABLE 实际上不依赖 DROP 权限，而是依赖 DROP + CREATE 组合权限（MySQL 8.0+ 更明确要求 TRUNCATE 权限）。即使你 REVOKE DROP ON db.tbl FROM 'u'@'%'，只要用户有 CREATE 和对表的 DELETE 权限，TRUNCATE 仍可能成功——因为 MySQL 内部把它实现为「DROP + CREATE 同名空表」。
真正有效的禁止方式：只给最小必要权限
禁用 TRUNCATE 的核心是切断其底层依赖。MySQL 8.0.23+ 支持独立的 TRUNCATE 权限，但旧版本（如 5.7、8.0.22-）不识别该权限，必须从源头控制：
- 显式
REVOKE DROP, CREATE ON db.* FROM 'u'@'%'（注意不是db.tbl，因为CREATE是库级权限） - 只授予
SELECT, INSERT, UPDATE, DELETE（不含ALTER或INDEX，除非真需要） - 避免授予
ALL PRIVILEGES ON db.*—— 这会隐式包含CREATE - 若业务需建临时表，改用
CREATE TEMPORARY TABLES权限，它不影响普通表操作
验证用户是否还能 TRUNCATE 的实操检查
别只信权限列表，要实测。用目标用户登录后执行：
TRUNCATE TABLE test_table;
如果报错 ERROR 1142 (42000): TRUNCATE command denied to user 'u'@'%' for table 'test_table'，说明生效；如果报 ERROR 1051 (42S02): Unknown table 'db.test_table'，说明用户连表都看不见，权限过严了。常见误判点：
-
SHOW GRANTS FOR 'u'@'%'输出里没看到DROP，不代表安全——可能通过角色继承获得 - 使用
mysql_native_password认证的用户，在权限变更后需FLUSH PRIVILEGES -
TRUNCATE在事务中不可回滚，但权限检查发生在语句解析阶段，和事务隔离无关
替代方案：用存储过程封装写操作（适合高敏场景）
当权限模型仍不放心时，可完全屏蔽直接 DDL/DML，把数据清理逻辑收口到存储过程中：
DELIMITER $$ CREATE PROCEDURE safe_clear_table() BEGIN DELETE FROM target_table WHERE 1=1; -- 不用 TRUNCATE，不触发 AUTO_INCREMENT 重置（如需保留计数器） END$$ DELIMITER ;
然后只授 EXECUTE 权限给用户，同时 REVOKE DELETE ON db.target_table。这样既满足清空需求，又彻底规避 TRUNCATE 调用路径。
复杂点在于：MySQL 的存储过程权限检查是调用时校验，不是定义时；且 SQL SECURITY DEFINER 需谨慎设置拥有者账号——它决定了执行时以谁的权限运行。
