MySQL 清空表数据
DELETE 语句和 TRUNCATE TABLE 命令都用于从数据表中移除数据，但它们在数据库引擎的底层操作层面完全不同，这导致了它们在性能、日志记录和功能特性上存在着显著的差异。
1. DELETE 语句：逐行处理
DELETE 是一种数据操作语言 (DML, Data Manipulation Language) 命令。当你执行 DELETE 语句时——即使目标是表中的每一行——MySQL 引擎也会将其视为一系列独立的单行操作。
-- 删除符合特定条件的行
DELETE FROM orders WHERE status = 'cancelled';
-- 删除表中的所有行
DELETE FROM orders;当你运行 DELETE 时，数据库引擎会扫描表，识别出符合你设定的标准的每一行，检查任何相关的约束（比如触发器 Triggers 或外键 Foreign Keys），然后逐个移除记录。因为这是在逐行的基础上发生的，所以 MySQL 会在事务日志中记录每一次删除操作。
这就是为什么 DELETE 是支持事务的：如果你使用的是像 InnoDB 这样的存储引擎，当你意识到自己犯了错误时，你可以在提交 (Commit) 之前回滚 (Rollback) 这个事务来恢复数据。
然而，这种逐行处理的方法在计算上是非常昂贵的。如果你有一个包含数百万行数据的表，执行无条件的 DELETE 将会非常缓慢，消耗大量的 CPU 资源，并导致你的事务日志体积暴增。
2. TRUNCATE TABLE 命令：重置数据表
TRUNCATE TABLE 是一种数据定义语言 (DDL, Data Definition Language) 命令。它不是通过扫描和移除行来工作，而是本质上直接删除（Drop）现有的表，并用相同的结构重新创建它。
TRUNCATE TABLE orders;因为它是重新创建表，所以 TRUNCATE 不会进行逐行扫描。它会忽略所有行级别的约束和触发器，并且不会在事务日志中记录单行数据的删除。这使得它的执行速度几乎是瞬间的，无论表中包含多少条记录。
最关键的一点是，如果你的表包含一个 AUTO_INCREMENT（自增）列，TRUNCATE 会将该计数器重置回它的初始值（通常是 1）。DELETE 不会这样做；它会让自增计数器保持在删除前的位置继续递增。
3. 功能全面对比
| 特性 | DELETE | TRUNCATE TABLE |
|---|---|---|
| 命令类型 | DML (数据操作语言) | DDL (数据定义语言) |
| 执行性能 | 慢 (逐行处理) | 极快 (直接删除并重建表) |
| WHERE 子句 | 支持 (可精细过滤) | 不支持 (只能清空全表) |
| 自增列 (Auto-Increment) | 保持当前计数值 | 重置为初始值 |
| 事务支持 | 可以回滚 (Rollback) | 通常隐式提交，无法回滚 |
| 触发器 (Triggers) | 会触发 DELETE 触发器 | 不会触发任何触发器 |
决策逻辑参考：
- 需要过滤特定的行吗？ → 使用带有 WHERE 的 DELETE
- 不需要过滤，且需要重置自增 ID 吗？ → 使用 TRUNCATE TABLE
- 不需要过滤，不重置 ID，但是数据集极大？ → 推荐使用 TRUNCATE TABLE (速度更快)
4. 约束与安全机制
因为 TRUNCATE 是一个 DDL 命令，它在 MySQL 中对待事务的行为有所不同。在许多配置下，执行 TRUNCATE 会引发一次隐式的“提交 (commit)”，这意味着你无法回滚该操作。一旦截断，数据就立刻消失了。
此外，如果当前表被另一个表通过 FOREIGN KEY（外键）约束所引用，TRUNCATE 将会执行失败。虽然 DELETE 在违反引用完整性时也会失败，但由于 DELETE 允许使用 WHERE 子句，它提供了所需的颗粒度，使你能够以尊重这些关联关系的方式移除特定行。而 TRUNCATE 则强制要求你必须先删除或禁用外键才能执行。