收回 DROP 和 CREATE 权限不能阻止 TRUNCATE，因为 TRUNCATE 依赖 DELETE 或 ALTER 权限而非 DROP/CREATE，其底层虽类似重建表但绕过标准权限校验；真正有效的是 revoke DELETE、ALTER 并结合角色隔离、SQL 审计与代理层拦截。
为什么收回 DROP 和 CREATE 权限不能阻止 TRUNCATE
因为 TRUNCATE TABLE 在 MySQL 中本质上是 DDL 操作，但它的权限检查逻辑和 DROP/CREATE 不同：只要用户有 DELETE 权限（或表级 ALTER 权限），在多数 MySQL 版本（5.7/8.0）中就能执行 TRUNCATE——它底层会先 DROP 再 CREATE 表，但不走标准的权限校验路径。所以光 revoke DROP 和 CREATE 对防止 TRUNCATE 几乎无效。
真正有效的权限控制方式
MySQL 8.0.21+ 引入了细粒度的 TABLE_ENCRYPTION_ADMIN 等新权限，但对 TRUNCATE 的限制仍依赖组合策略。生产环境最可靠的做法是：
- 只授予最小必要权限：
SELECT、INSERT、UPDATE、DELETE（注意：DELETE权限本身允许TRUNCATE，所以必须慎用） - 显式 revoke
ALTER权限（TRUNCATE在部分场景下会触发ALTER检查） - 对关键库/表，使用
REVOKE TRIGGER, ALTER, DROP, CREATE, INDEX, REFERENCES ON db.table FROM 'user'@'%' - MySQL 8.0 推荐启用
sql_mode = 'STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'，虽不直接拦截TRUNCATE，但能减少误操作连带影响
用角色（ROLE）隔离开发与生产权限更稳妥
MySQL 8.0+ 支持角色管理，比直接给用户授予权限更可控：
- 创建只读角色：
CREATE ROLE 'dev_ro'; GRANT SELECT ON prod_db.* TO 'dev_ro'; - 创建受限写入角色（不含
TRUNCATE能力）：CREATE ROLE 'dev_rw'; GRANT SELECT, INSERT, UPDATE ON prod_db.* TO 'dev_rw'; REVOKE DELETE ON prod_db.* FROM 'dev_rw';（注意：删掉DELETE是关键，因TRUNCATE依赖它） - 禁止开发账号拥有任何角色：
SET DEFAULT ROLE NONE FOR 'dev_user'@'%';，再按需动态SET ROLE 'dev_ro'
这样即使账号密码泄露，没显式激活角色也无法执行高危操作。
补充防御：SQL 审计 + 代理层拦截
权限只是第一道防线。真实生产环境里，仅靠 MySQL 自身权限模型无法 100% 防住 TRUNCATE：
-
mysqlauditlog或企业版 Audit Plugin 可记录所有TRUNCATE语句，便于事后追溯 - 在中间件层（如 ProxySQL、MaxScale）配置 SQL 黑名单规则，匹配
^TRUNCATE[[:space:]]+TABLE并拒绝执行——这是目前最直接有效的实时拦截手段 - 应用连接串强制指定
read_only=1（对从库）或使用SET SESSION sql_log_bin = 0配合权限限制，但要注意这不阻止TRUNCATE本身
真正难防的是有 DELETE 权限又知道 TRUNCATE 语义的开发人员——权限回收必须配合流程（如 DBA 审批才开临时写权限）和工具（SQL 审核平台卡点），单靠 REVOKE 命令远远不够。
