TRUNCATE 彻底清空表并重置自增主键，不支持 WHERE、不触发触发器、需 DROP 权限、隐式提交事务；DELETE 逐行删除、保留自增值、支持条件与事务回滚、触发行级触发器、产生大量日志。
TRUNCATE 和 DELETE 的执行效果差异
TRUNCATE 会彻底清空表数据并重置自增主键计数器，DELETE 则逐行删除，不重置 AUTO_INCREMENT 值（除非显式 ALTER TABLE ... AUTO_INCREMENT = 1）。这意味着：如果表里原来有 1000 条记录、AUTO_INCREMENT 已到 1001，执行 TRUNCATE 后下一条插入的 ID 是 1；而 DELETE FROM table 后下一条插入的 ID 是 1001。
TRUNCATE 无法带 WHERE 条件，DELETE 可以
TRUNCATE 是 DDL 操作，语法上不支持 WHERE 子句，只能清空整张表。而 DELETE 是 DML，支持完整条件过滤：
DELETE FROM users WHERE status = 'inactive';
常见误操作：把 DELETE FROM users; 写成 TRUNCATE users; 看似等价，但若后续依赖自增值连续性或触发器逻辑，行为完全不同。
事务与回滚能力不同
DELETE 在事务中可回滚，TRUNCATE 多数 MySQL 存储引擎（如 InnoDB）下虽能回滚，但实际依赖于是否开启事务及 binlog 格式；更关键的是：TRUNCATE 会隐式提交当前事务，执行后无法再用 ROLLBACK 撤销之前的操作。
-
DELETE：受事务控制，可配合START TRANSACTION安全测试 -
TRUNCATE：发出即生效，即使在事务块内，也会立即释放页空间、重建表结构 - MyISAM 表上
TRUNCATE不支持回滚，InnoDB 表上虽可回滚，但代价高、不推荐依赖
权限、触发器与锁机制区别
TRUNCATE 需要 DROP 权限（而非 DELETE
ON DELETE 触发器；DELETE 则会正常激活所有定义的行级触发器。
锁表现也不同：
-
DELETE对每行加行锁，可能引发锁等待或死锁，尤其大表未加索引的 WHERE 条件 -
TRUNCATE加的是表级元数据锁（META DATA LOCK），阻塞其他 DDL，但不与普通 SELECT 冲突（除非显式LOCK TABLES） -
TRUNCATE不写入 undo log，日志体积小；DELETE会产生大量 undo 和 redo 日志，大表慎用
真正需要“快速清空+重置自增+无触发逻辑”的场景才选 TRUNCATE；只要涉及条件、审计、触发器或需事务包裹，就只能用 DELETE。别因为 TRUNCATE 快就默认替换 DELETE —— 自增 ID 跳变和权限报错 ERROR 1142 (42000): TRUNCATE command denied 是线上最常被忽略的两个坑。
