TRUNCATE性能远高于DELETE，因TRUNCATE是DDL操作仅记录页释放动作、日志量恒定KB级，而DELETE是DML操作需为每行生成日志，100万行产生约200MB日志。
TRUNCATE 不记录行日志，DELETE 每删一行都写日志
这是性能差距的底层原因：DELETE 是 DML 操作，SQL Server/MySQL/Oracle 都会为每一行生成 DELETE 日志条目（如 SQL Server 的 LOP_DELETE_ROWS，MySQL 的 undo log + binlog）。100 万行 = 至少 100 万条日志写入，I/O 和日志空间压力陡增。TRUNCATE 是 DDL 操作，只记录页释放动作（如 LOP_MODIFY_ROW 更新 IAM/PFS 页面），日志量几乎恒定在 KB 级。
- 实测 100 万行表：
DELETE FROM t产生约 200MB 日志；TRUNCATE TABLE t日志增长 - 高并发下，DELETE 可能触发日志文件自动扩容、阻塞 checkpoint，TRUNCATE 基本不扰动日志子系统
- MySQL InnoDB 中，DELETE 还要维护 purge 线程清理标记删除的行，TRUNCATE 完全绕过这套机制
TRUNCATE 在大多数数据库里不能回滚，但 SQL Server 是个例外
别信“所有数据库 TRUNCATE 都不可回滚”这种笼统说法——它在 SQL Server 中确实支持事务回滚，但在 MySQL 和 Oracle 中不行。这直接决定你敢不敢在生产脚本里用 TRUNCATE。
- MySQL：
START TRANSACTION; TRUNCATE TABLE t; ROLLBACK;→ 表已空，无法恢复 - Oracle：
TRUNCATE是隐式提交，执行即生效，ROLLBACK无效 - SQL Server：
BEGIN TRAN; TRUNCATE TABLE t; ROLLBACK;→ 数据完整还原（但需注意：若表被引用外键或参与索引视图，仍会报错） - 真正保险的做法：先
CREATE TABLE t_bak AS SELECT * FROM t（MySQL）或SELECT INTO（SQL Server），再操作
DELETE 能走 WHERE 条件和触发器，TRUNCATE 不能
如果你需要删数据的同时更新统计表、发通知、校验业务规则，TRUNCATE 直接出局。它不触发任何 DELETE 触发器，也不支持条件过滤。
- 常见误用：
TRUNCATE TABLE orders WHERE status = 'canceled'→ 语法错误，直接报错 - 替代方案：用
DELETE FROM orders WHERE status = 'canceled'，再手动UPDATE STATISTICS orders（SQL Server）或ANALYZE TABLE orders（MySQL）避免执行计划劣化 - 若只是清空临时表且需触发清理逻辑，宁可建一个空表
CREATE TABLE orders_new LIKE orders，再RENAME TABLE切换，比 DELETE 更可控
自增 ID 重置 vs 保留，不是性能问题，而是业务连续性问题
TRUNCATE 会把 AUTO_INCREMENT 或 IDENTITY 计数器归零，DELETE 不会。这看起来是小细节，但可能引发下游系统主键冲突、ID 重复预警甚至订单号断层。
- MySQL 示例：原表最大 ID 是 999999，
TRUNCATE后第一条新记录 ID=1；DELETE FROM t后第一条新记录 ID=1000000 - SQL Server 中，
DBCC CHECKIDENT('t', RESEED, 0)可模拟 TRUNCATE 的重置效果，但需额外权限且非原子操作 - 关键判断点：查一下业务是否依赖“ID 单调递增且不重复”——如果依赖，别用 TRUNCATE；如果只是内部计数，TRUNCATE 更干净
真实线上环境里，最常被忽略的是外键约束和索引视图限制：TRUNCATE TABLE 遇到被其他表外键引用，或者表本身被定义在索引视图中，会直接报错退出，而 DELETE 只要没开级联，至少能跑起来（哪怕慢）。动手前，先 SELECT FROM sys.foreign_keys WHERE referenced_object_id = OBJECT_ID('t')（SQL Server）或 SELECT FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 't'（MySQL）扫一眼。
