删除数据是日常开发中最需要谨慎对待的操作之一。MySQL 提供了两种最常用的删除方式：DELETE 和 TRUNCATE。它们都能让数据从表中消失，但背后的机制、性能表现和适用场景差异巨大。用错不仅影响性能，严重的还会误删数据、影响自增值，甚至触发不必要的锁等待。
8.3.1 DELETE：逐行删除，可控但代价高
DELETE 是标准的 DML 语句，用于从表中移除满足条件的行。它的基本语法为：
DELETE FROM 表名 WHERE 条件;如果省略 WHERE 子句，会删除表中所有行，但表结构、索引、约束都保留，属于清空表的写法。
DELETE 的内部执行过程
DELETE 是逐行删除。InnoDB 引擎会对每一行加锁，记录 Undo Log（方便回滚），在删除的同时维护索引。这些动作使得删除数据的成本很高：
- 产生的 Undo Log 大：每删除一行，就要在 Undo 中记录一条反向操作（插入该行），事务越长、删除行越多，Undo 占用越大。
- 不会立即回收磁盘空间：删除后在 InnoDB 表空间内只是标记这些行所占用的空间为可复用，并不会收缩文件。只有等到新的 INSERT 复用这些空间，或者主动执行
OPTIMIZE TABLE重建表，才会真正归还空间给操作系统。 - 可能触发页分裂和索引调整：删除行造成页内空闲变大，如果删除掉大量行，可能会导致索引页碎片化和效率降低。
- 受事务和锁影响：DELETE 是事务内的操作，删除的行在事务提交前都被锁定，其他事务必须等待。大范围删除容易引发长事务、锁等待甚至死锁。
DELETE 的可控性优势
尽管代价高，DELETE 也有不可替代的优点：
- 可以带 WHERE 条件：你可以有选择地删除部分行，满足特定业务逻辑，比如删除过期的日志、清理某个用户的无效订单。
- 可触发触发器：如果表上定义了 DELETE 触发器，使用 DELETE 删除数据时会触发，TRUNCATE 则不会。
- 可回滚：只要在事务里执行，发生错误可以回滚。这使得 DELETE 适合需要安全保证的精细删除。
DELETE 的性能注意事项
- 大量删除数据时，避免在一个事务里一次性删除几百万行，这会导致长事务、Undo 暴涨，还可能锁住过多行，阻塞其他业务。正确做法是分批删除：每次删 1000~10000 行，提交一次事务，循环直到删完。通常在脚本中实现，或者在存储过程中配合
LIMIT使用。 - 全表删除不建议用
DELETE FROM 表名;（不加 WHERE），因为同样会逐行记录 Undo。如果只是想快速清空一张大表，TRUNCATE 是更优的选择。
8.3.2 TRUNCATE：快速清空，DDL 的暴力优雅
TRUNCATE 的语法很简单：
TRUNCATE TABLE 表名;它看起来很像 DELETE 的全表删除，但本质完全不同。TRUNCATE 属于 DDL（数据定义语言），而不是 DML。这意味着它不是逐行删除数据，而是直接删除并重建表或释放数据页，从而极速完成清空。
TRUNCATE 的内部机制
- 在 InnoDB 中，
TRUNCATE通常会执行以下操作：创建一个与原表结构相同的新表，删除原表，再将新表重命名为原表。或者说，直接释放表空间文件的全部数据页（在独立表空间下可以瞬间完成）。正因如此，它几乎不产生 Undo Log，不需要逐行锁定。 - 执行完后，磁盘空间立刻归还操作系统（独立表空间模式下），表恢复为最初创建时的大小。
- 自增计数器重置为初始值（通常是 1），这一点与 DELETE 不同。
TRUNCATE 的特点与限制
优点显而易见：
- 极快：无论表中有几千万行还是几亿行，TRUNCATE 都几乎是瞬间完成，因为它不是在删数据，而是在重建表。
- 不产生大量日志和锁：没有逐行的 Undo 和行锁，执行时通常只需要短暂的元数据锁。
- 空间立即回收：没有碎片，表文件直接变小。
但同时也有很多值得注意的限制：
- 不能带 WHERE 条件：只能清空整张表，无法筛选保留部分数据。
- 不能回滚：因为 TRUNCATE 是隐式提交的 DDL，语句执行后就自动提交了当前事务，无法回滚。如果误操作了，只能依赖备份恢复。
- 不触发 DELETE 触发器：如果你有审计触发器需要记录删除行为，TRUNCATE 会绕过它。
- 外键约束限制：如果表被其他表的外键引用，TRUNCATE 会失败。即使你清空的是父表，子表有外键约束也不能直接 TRUNCATE（除非子表使用了
ON DELETE CASCADE，但即使这样也不行，因为 TRUNCATE 不会触发级联删除）。 - 需要 DROP 权限：实际上执行 TRUNCATE 需要表的 DROP 权限，而不是 DELETE 权限。
什么时候用 TRUNCATE
- 你想快速清空一张临时表、日志表、报表中间结果表。
- 表数据量巨大，用 DELETE 全删会导致长时间锁表和大量日志。
- 你确定要清空全部数据，并且不需要回滚和触发触发器。
如果业务要求必须记录每一条删除的历史，或者需要根据条件保留部分数据，TRUNCATE 无法胜任，还是得老老实实用 DELETE 加 WHERE。
8.3.3 DELETE 与 TRUNCATE 核心区别一览
| 对比项 | DELETE | TRUNCATE |
|----------------------|-------------------------------------------|-----------------------------------------|
| 语言分类 | DML | DDL |
| 可否带 WHERE 条件 | 可以 | 不可以 |
| 是否逐行删除并记录 Undo | 是，逐行删除，逐行记录 Undo | 否，直接释放数据页或重建表 |
| 速度（大表全删） | 慢，随数据量线性增长 | 极快，几乎恒定时间 |
| 事务支持 | 支持，可以回滚 | 不支持，隐式提交，无法回滚 |
| 触发器 | 触发 DELETE 触发器 | 不触发 |
| 自增值（AUTO_INCREMENT）| 保留当前值（不重置） | 重置为初始值 |
| 空间回收 | 不立即回收，原空间标记可复用 | 立即回收（独立表空间） |
| 所需权限 | DELETE 权限 | DROP 权限 |
| 外键约束 | 按约束规则执行（可能报错或级联） | 若被外键引用则失败 |
8.3.4 安全删除的实用建议
不论用哪种方式删除数据，安全永远第一。几个习惯值得养成：
- 执行删除前先 SELECT 核对：如果用 DELETE，先用同样的 WHERE 条件执行一次
SELECT COUNT()或SELECT看看到底会删除哪些数据，确认无误再执行 DELETE。 - 大数据量 DELETE 务必分批分批提交：一次删 5 万行提交一次，避免长事务和锁表。类似
DELETE FROM logs WHERE create_time < '2023-01-01' LIMIT 10000;循环执行，可以写成脚本或存储过程。 - 避免在业务高峰期做大批量删除：即使是分批 DELETE，也会产生 I/O 压力和锁竞争，尽量放在低峰时段执行。
- 使用 TRUNCATE 前务必三思：因为不可回滚，最好先确认备份，并且在测试环境演练。在生产环境中，尽量避免对核心业务表直接 TRUNCATE。
- 开启 binlog 格式为 ROW：如果是主从架构，用 ROW 模式 binlog 时，DELETE 会记录每一行删除的数据，TRUNCATE 则记录 DDL 语句。这在数据恢复和审计上更可追踪。
- 善用工具：对于超大表的彻底删除和空间回收，可以辅助
pt-archiver（Percona Toolkit）进行更优雅的滚动删除，甚至可以结合OPTIMIZE TABLE重建表以回收碎片（但要注意它会锁表，在 8.0 中可以使用ALGORITHM=INSTANT或INPLACE来减少影响）。
总之，DELETE 是外科手术刀，精准但耗时；TRUNCATE 是推土机，迅猛但不可逆。根据场景选择合适的方式，并在执行前做好充分检查，是每个后端开发者的必备习惯。