MySQL 清空表数据用 TRUNCATE 还是 DELETE

sql DELETE FROM table_name;

但更规范的清空全表写法是省略 `WHERE`：
```sql
DELETE FROM table_name;   -- 逐行删除，记录日志

1.2 TRUNCATE 清空表

TRUNCATE 属于 DDL（数据定义语言），作用是快速清空整张表的所有数据：

TRUNCATE [TABLE] table_name;

它是通过删除原表并重建一张结构相同的空表来实现的，而非逐行操作。

2. 五大关键区别深度解析

2.1 操作本质与性能

• DELETE：逐行扫描并删除数据。每删除一行都会在事务日志（undo log）中记录详细的行级变更，并且可能触发删除触发器。当表数据量很大时，DELETE 会非常缓慢，因为需要消耗大量 I/O 和 CPU 来记录日志、维护索引。
• TRUNCATE：直接删除数据文件并重建 .ibd 文件（InnoDB），或者逐页回收空间（取决于存储引擎）。它不会逐行记录删除日志，只记录整个表空间的释放操作。因此 TRUNCATE 的执行速度通常与表数据量无关，几乎是瞬时完成。

性能结论：在大数据量场景下，TRUNCATE 的执行效率远高于 DELETE。

2.2 事务与回滚行为

• DELETE：完全支持事务。如果在事务中执行 DELETE FROM table_name 并尚未提交，可以使用 ROLLBACK 恢复所有被删除的数据。这得益于它逐行记录 undo log。
• TRUNCATE：在 MySQL 5.x 部分版本中，TRUNCATE 属于隐式提交的 DDL 语句，执行后不能回滚。但从 MySQL 5.7 及以后，对于 InnoDB 存储引擎，TRUNCATE 在事务内变得部分可回滚（实际上是原子操作，但在某些隔离级别下可能回滚）。然而，官方仍强烈建议将其视为不可回滚的操作，因为它不像 DELETE 那样记录每一行 undo 信息。在生产环境中，切勿依赖于 TRUNCATE 的回滚能力。

2.3 自增列（AUTO_INCREMENT）处理

这个区别极易被忽略，却是业务逻辑的关键：

• DELETE 清空全表后，自增计数器不会被重置。下次插入新行时，AUTO_INCREMENT 值会接着之前的序号继续递增。
• TRUNCATE 清空全表后，自增计数器会被重置为起始值（通常为 1）。这意味着新插入的行 ID 会从 1 开始重新分配。

如果你希望清空数据后让主键 ID 重新从 1 开始，应选择 TRUNCATE；若必须保留主键序列的延续性，则必须使用 DELETE。

2.4 触发器（Trigger）与外键约束

• DELETE：会激活表上定义的 BEFORE DELETE 和 AFTER DELETE 触发器。如果存在外键约束且设置为 ON DELETE CASCADE，则删除主表数据会级联删除子表关联数据。同时，若外键约束检查失败，删除会报错。
• TRUNCATE：不会激活 DELETE 触发器。此外，如果一张表被其他表的外键引用（作为父表），即使没有任何子相关数据，MySQL 也不允许对该表执行 TRUNCATE，会直接报错：Cannot truncate a table referenced in a foreign key constraint。若想 TRUNCATE 被外键引用的表，需先删除外键或使用 SET FOREIGN_KEY_CHECKS=0（极不推荐在生产中随意使用）。

2.5 WHERE 条件与灵活性

• DELETE：支持 WHERE 子句，可以精确删除符合条件的数据，灵活性高。
• TRUNCATE：不支持 WHERE 条件，只能清空整张表，无法部分删除。

3. 使用场景最佳实践

3.1 优先使用 TRUNCATE 的场景

• 你需要快速清空临时表、日志表、接口中间表等大量数据。
• 清空后希望自增 ID 重新计数。
• 表上没有定义对业务逻辑关键的 DELETE 触发器。
• 表不被其他表的外键引用，或者你可以先清理外键关系。
• 确认操作不需要回滚能力。

3.2 必须使用 DELETE 的场景

• 需要删除部分数据，而不是整表。
• 表上有重要的 DELETE 触发器，必须触发这些逻辑（如审计日志、同步缓存失效等）。
• 必须保留自增 ID 的当前序列。
• 表被其他表外键引用，但你不希望修改表结构，只想清空数据；此时可配合 ON DELETE CASCADE 或手动先删子表数据。
• 需要在事务中清空数据并保留回滚的可能性（虽然 DELETE 资源消耗大，但安全性高）。

4. 常见陷阱与避坑指南

• 在生产环境贸然使用 TRUNCATE：TRUNCATE 执行后无法通过 ROLLBACK 恢复，即使开启了 binlog，点播恢复也可能复杂。务必先在测试环境确认。
• 外键报错：当提示 Cannot truncate a table ... foreign key constraint 时，检查子表中是否还有关联数据，或者只是外键定义存在。即使子表无数据，外键约束本身就会阻止 TRUNCATE。正确做法是先 DELETE 子表数据，再 TRUNCATE 父表，或临时删除外键。
• 对带有触发器的表误用 TRUNCATE：导致审计记录缺失，数据一致性被破坏。
• 误认为 TRUNCATE 重置自增 ID 一定从 1 开始：如果之前自增列手动插入了更大的值，TRUNCATE 后自增计数器可能从 1 开始，但如果表为空时使用 ALTER TABLE ... AUTO_INCREMENT = N 设置了初始值，那么 TRUNCATE 会重置为 1，而非你设置的值（取决于 MySQL 版本）。验证方法：TRUNCATE 后通过 SHOW CREATE TABLE table_name 查看 AUTO_INCREMENT 值，或直接插入测试数据。

5. 综合对比速查表

6. 动手验证（安全环境）

你可以通过以下步骤在自己的测试库中观察区别：

-- 创建测试表并插入数据
CREATE TABLE test_clear (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(20)
) ENGINE=InnoDB;

INSERT INTO test_clear (name) VALUES ('a'), ('b'), ('c');

-- 查看当前自增值
SHOW CREATE TABLE test_clear;  -- AUTO_INCREMENT=4

-- 使用 DELETE 清空
DELETE FROM test_clear;
INSERT INTO test_clear (name) VALUES ('d');
SELECT * FROM test_clear;      -- id 为 4

-- 使用 TRUNCATE 清空
TRUNCATE TABLE test_clear;
INSERT INTO test_clear (name) VALUES ('e');
SELECT * FROM test_clear;      -- id 为 1