TRUNCATE 不走事务日志且不生成 undo log，DELETE 会写满 undo log；TRUNCATE 是 DDL 操作，直接释放数据页并重置 AUTO_INCREMENT，不可回滚、不支持 WHERE；DELETE 是 DML 操作，逐行删除、可回滚、支持条件过滤、不重置自增值。
Truncate 不走事务日志，Delete 会写满 undo log
MySQL 的 DELETE 是 DML 操作，每删一行都生成一条 undo log 记录，用于事务回滚和 MVCC；同时还会写 redo log 确保崩溃可恢复。哪怕删空整张表，也要逐行扫描、逐行标记、逐行记录——数据量越大，undo log 越多，写盘压力越重，锁粒度（如行锁）也持续更久。
TRUNCATE 是 DDL 操作（虽语法像 DML），本质是「重建表结构」：它直接释放原表的所有数据页（InnoDB 中即清空 ibd 文件的页链表），然后新建一个空段（segment）。不生成 undo log，也不进事务日志缓冲池（log_buffer），自然没回滚能力——这也是它不能在事务中安全使用的原因。
-
DELETE FROM t在事务中可回滚；TRUNCATE TABLE t执行即生效，遇到ROLLBACK无效 - 大表
DELETE可能触发innodb_log_file_size写满，导致刷盘阻塞；TRUNCATE完全绕过这层 - 有外键引用的表，
TRUNCATE直接报错ERROR 1701 (HY000): Cannot truncate a table referenced in a foreign key constraint，而DELETE只要满足约束仍可执行
Truncate 重置 AUTO_INCREMENT，Delete 不重置
这是开发最常踩的坑之一：TRUNCATE 会把表的 auto_increment 值重置为 1（或 MIN(1, offset)），而 DELETE 后再插入，ID 会从上次最大值 +1 继续递增。原因在于 TRUNCATE 实际调用了 ha_innobase::truncate()，内部重载了表元数据（包括 dict_table_t::autoinc 字段），而 DELETE 只操作数据行，不动表定义缓存。
- 如果业务依赖自增 ID 的连续性或单调递增（比如用作外部系统序列号），
TRUNCATE后首次插入可能撞上旧 ID，引发冲突 -
SHOW CREATE TABLE t看不到当前 autoinc 值；得查SELECT AUTO_INCREMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t' - 5.7+ 支持
ALTER TABLE t AUTO_INCREMENT = N手动重设，但需注意该语句本身也会触发表重建（隐式 DDL），对大表仍有风险
Truncate 无法带 WHERE 条件，Delete 可以精确过滤
TRUNCATE 语法强制无条件，只作用于整表；DELETE 支持 WHERE 子句，支持索引下推、范围扫描、甚至子查询。这意味着：想清空某个时间分区的数据、按状态归档后再清理，只能用 DELETE（或 PARTITION 操作）。
- 误写成
TRUNCATE TABLE t WHERE created_at 会直接报错 <code>ERROR 1064 (42000): You have an error in your SQL syntax - 带
WHERE的DELETE若没走索引，可能全表扫描+全行加锁，比TRUNCATE还慢且更耗资源 - 对于分区表，
ALTER TABLE t DROP PARTITION p_old的性能和语义更接近TRUNCATE，且支持条件化删除，是大表归档的更优解
InnoDB 数据页层面：Truncate 是段级释放，Delete 是行级标记
InnoDB 存储引擎里，TRUNCATE 直接调用 fil_space_truncate() 清空表空间中的所有区（extent）和页（page）链表，把整个 FIL_PAGE_TYPE_FSP_HDR 和 FIL_PAGE_TYPE_XDES 元数据重置；而 DELETE 只是在每个数据页的 page_dir_slot 中把对应记录标记为「已删除」（REC_INFO_DELETED_FLAG），物理空间并不立即回收——直到后续 INSERT 复用或 OPTIMIZE TABLE 触发页合并。
- 所以
TRUNCATE后SELECT COUNT(*)必然为 0，且data_length在INFORMATION_SCHEMA.TABLES中立刻变小；DELETE后data_length几乎不变，磁盘文件大小也不缩 - 频繁
DELETE+INSERT容易导致页碎片，innodb_page_size利用率下降；TRUNCATE后新写入的数据页是连续紧凑的 -
TRUNCATE期间会持有S（共享）MDL 锁，阻塞 DDL；而大事务DELETE可能长期持有X行锁或间隙锁，阻塞读写，影响更大
