TRUNCATE 比 DELETE 更快，因直接释放数据页并重置元数据，不写 undo log 和逐行 binlog；但不可回滚、重置自增 ID、不触发触发器，且在事务中会隐式提交。
DELETE 是逐行操作，TRUNCATE 是 DDL 级清空
DELETE 会一行一行扫描、加锁、写入 undo log 和 binlog（如果开启），还要触发 ON DELETE 触发器；TRUNCATE 则直接释放数据页，重置表的元数据（包括自增 ID），不走事务日志路径（InnoDB 中本质是 DROP + RECREATE 表结构的轻量版）。所以只要不需要回滚、不依赖 binlog 恢复、不关心触发器，TRUNCATE 几乎总是更快。
常见错误现象：TRUNCATE 在事务中执行会隐式提交，导致当前事务提前结束；DELETE 却可以回滚。若误在长事务里用 TRUNCATE，可能破坏事务一致性。
- 使用场景：清空测试表、ETL 中间表、日志归档后重置 —— 优先选
TRUNCATE - 限制条件：不能有外键引用该表；不能用于临时表（MySQL 8.0+ 支持，但需确认版本）；不能带 WHERE 条件
- 性能影响：大表上
TRUNCATE耗时基本与表大小无关，而DELETE FROM t可能卡住几秒到几分钟，还可能撑爆innodb_log_file_size
高水位线（HWM）是否重置取决于存储引擎和操作类型
InnoDB 的“高水位线”实际反映的是聚簇索引最大页号或 ibdata1 中已分配但未回收的空间。DELETE 不释放磁盘空间，只打删除标记（purge 稍后异步清理），HWM 不降；TRUNCATE 会真正释放段（segment），重置 auto_increment，并把表空间文件（如 .ibd）收缩回初始大小（前提是 innodb_file_per_table=ON）。
容易踩的坑：OPTIMIZE TABLE 能让 DELETE 后的空间回收，但它会锁表、重建表，开销接近 TRUNCATE；而很多人误以为 DELETE + ANALYZE TABLE 就能降 HWM —— 实际上 ANALYZE TABLE 只更新统计信息，不释放空间。
-
TRUNCATE后立即SHOW TABLE STATUS查看Data_length，可验证是否真收缩 - 若表使用共享表空间（
innodb_file_per_table=OFF），TRUNCATE 仍无法回收ibdata1空间，必须导出再重建实例 - 对于分区表，
TRUNCATE PARTITION p1可精准释放某分区 HWM，比全表 DELETE 高效得多
日志开销差异直接影响主从延迟与恢复时间
DELETE 每行生成 undo log（用于 MVCC 和回滚），每条语句还写一条 binlog（statement 或 row 格式）；TRUNCATE 不写 undo log（不可回滚），binlog 中只记一条 DDL 事件（TRUNCATE TABLE t），体积小、解析快。这意味着：主库执行 TRUNCATE 几乎不拖慢 binlog dump 线程，从库也几乎无回放压力。
典型问题：DELETE FROM huge_log_table 在主库跑 5 分钟，binlog 写入数百 MB，从库可能延迟十几分钟；换成 TRUNCATE，延迟几乎为零。但要注意：ROW 格式下，大 DELETE 的 binlog 可能触发 max_binlog_stmt_size 截断，报错 Statement is unsafe... —— TRUNCATE 完全避开这类问题。
- binlog_format=ROW 时，DELETE 的日志体积 ≈ 行数 × 平均行大小；TRUNCATE 日志固定约 100 字节
- 开启
innodb_undo_log_truncate也无法缓解大 DELETE 对 undo 表空间的压力，TRUNCATE 则完全绕过 undo - 如果依赖 binlog 做闪回（如用
mysqlbinlog --flashback），TRUNCATE 无法还原，DELETE 至少还能解析出被删数据
TRUNCATE 不是万能的，某些边界情况反而更慢
当表上有大量二级索引、且 innodb_adaptive_hash_index=ON 时，TRUNCATE 会先清理 AHI 缓存，若缓存项极多（比如亿级热数据刚退出），这个清理过程可能卡住几百毫秒 —— 此时 DELETE 加 LIMIT 分批删，反而更平稳。另外，MySQL 5.7 中 TRUNCATE 对持有 MDL 锁的会话更敏感，容易因等待锁而超时。
最易被忽略的一点：TRUNCATE 会重置 auto_increment 计数器，但如果你的应用逻辑依赖“ID 持续递增不重复”，这个重置就是个 bug 而非优化。而 DELETE 保留原计数器，后续 INSERT 仍延续。
- 检查当前自增值：
SELECT AUTO_INCREMENT FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t' - 想清空又保留自增：只能用
DELETE，或ALTER TABLE t AUTO_INCREMENT = N手动设（N 要 ≥ 当前最大值） - 监控 TRUNCATE 是否卡住：查
performance_schema.events_statements_current中状态是否长期为executing
