SQL如何快速清空表数据？TRUNCATE与DELETE的区别
面对一张需要清空的表，是选择TRUNCATE TABLE还是DELETE FROM？这可不是一个随意的决定。两者的底层逻辑和执行后果天差地别，选错了，轻则性能拉胯，重则数据丢失、业务中断。一句话概括核心选择逻辑：要快速清空整张表，TRUNCATE TABLE是首选；如果需要条件删除、触发器响应或事务回滚能力，则必须用DELETE FROM。
TRUNCATE比DELETE快得多，但不能回滚、不能带WHERE条件
为什么TRUNCATE能快那么多？关键在于它们的执行机制完全不同。TRUNCATE属于DDL（数据定义语言）操作，它不关心表里具体有哪些数据行，而是直接释放存储数据的数据页，相当于把整本书的内容页一次性撕掉，只留下封面和目录。这个过程不记录每行的删除日志，所以极其迅速。
反观DELETE，它是标准的DML（数据操纵语言）操作。它会老老实实地遍历每一行，记录删除日志，触发相关的ON DELETE规则，并且整个过程受到事务控制。这就好比用橡皮擦一页一页地擦掉书里的每一个字，自然慢得多。
除了速度，还有几个关键行为差异必须牢记：
- 自增列处理：
TRUNCATE会重置自增列（比如MySQL的AUTO_INCREMENT或PostgreSQL的SEQUENCE），下次插入会从初始值开始。而DELETE只是删除数据，自增序列的当前值保持不变。 - 外键约束：在MySQL中，如果一个表被其他表的外键引用，直接执行
TRUNCATE会报错（Cannot truncate a table referenced in a foreign key constraint）。DELETE则可以在满足外键约束的前提下进行（例如级联删除）。 - 语法细节：SQL Server和PostgreSQL支持
TRUNCATE ... RESTART IDENTITY这样的语法来显式控制序列重置。MySQL则没有这个语法，如果需要重置自增列，得在TRUNCATE后手动执行ALTER TABLE ... AUTO_INCREMENT = 1。
DELETE FROM t1 和 DELETE FROM t1 WHERE 1=1 效果一样，但别这么写
有些开发者为了“保险起见”，喜欢写成DELETE FROM t1 WHERE 1=1，以为加个WHERE条件会更安全可控。其实，这完全是个心理安慰。数据库优化器一眼就能看穿这个恒真条件，最终执行计划依然是全表扫描并删除所有行，性能和直接写DELETE FROM t1没有任何区别，纯粹是多打了几个字符。
这里真正需要注意的，是MySQL的“安全更新模式”。当sql_safe_updates参数开启时（默认往往是开启的），MySQL会禁止执行没有WHERE条件或WHERE条件中未使用键列的DELETE和UPDATE操作，直接报错。这时你有两个选择：要么临时关闭安全模式（SET SQL_SAFE_UPDATES = 0;），要么在WHERE子句中显式地使用主键或索引列（例如WHERE id > 0）来绕过限制。
另外几个关于DELETE的冷知识：
- 数据库差异：PostgreSQL和SQL Server没有类似MySQL的安全更新模式，默认允许无
WHERE的DELETE操作，使用时更要格外小心。 - 锁的粒度：即使是只删除一行，
DELETE操作也可能产生锁。在MySQL的InnoDB引擎下，虽然是行级锁，但如果是通过全表扫描来定位要删除的行，或者在删除大量数据时，锁竞争可能升级，影响并发性能。 - 大表噩梦：对于数据量巨大的表，使用
DELETE清空简直是灾难。它会产生超长的事务、导致事务日志暴增、引发严重的主从复制延迟，在生产环境中应极力避免。
TRUNCATE 在不同数据库里的权限和行为细节
别看TRUNCATE命令短小精悍，它在不同数据库里的权限要求和行为细节各有各的“脾气”，跨数据库操作时尤其要注意：
- MySQL：执行
TRUNCATE需要用户拥有DROP权限，而不是DELETE权限。这是因为在底层，它被实现为“删除表并重新创建表结构”的组合操作。 - PostgreSQL：从9.5版本开始，引入了独立的
TRUNCATE权限。执行者需要拥有该权限或是表的OWNER。此外，TRUNCATE默认会级联清空所有通过继承关联的子表，除非你使用ONLY关键字明确指定只清空父表。 - SQL Server：它允许在
TRUNCATE后使用DBCC CHECKIDENT(‘table_name’, RESEED, 0)来精确重置标识列的种子值。但有个陷阱：如果表上还有未提交的插入事务，这个重置操作可能会失效。 - 通用关键区别：所有主流数据库中，
TRUNCATE操作都不会触发定义在表上的ON DELETE触发器。 这一点至关重要！如果你的业务逻辑依赖于删除触发器来发送消息、记录审计日志或清理关联缓存，那么使用TRUNCATE将会悄无声息地绕过这些逻辑，可能导致数据不一致。
大表清空的折中方案：分批 DELETE + 空表替换
现实场景往往更复杂：表太大了，直接用DELETE清空会锁表太久，影响线上业务；但又因为需要触发器或事务支持，不能用TRUNCATE。这时候，就需要一些“曲线救国”的折中方案：
- 空表替换法：这是非常巧妙的一招。先创建一个与原表结构完全相同的空表（
CREATE TABLE t1_new LIKE t1;），然后通过一个原子性的重命名操作完成切换（RENAME TABLE t1 TO t1_bak, t1_new TO t1;）。在MySQL中，这个操作是毫秒级的，对业务影响极小。之后可以慢慢处理备份表t1_bak中的数据。 - 分批删除法：如果必须用
DELETE，那就化整为零。通过DELETE FROM t1 WHERE id BETWEEN ? AND ?的方式，每次只删除一个批次的数据（比如1万行），每批完成后立即提交事务（COMMIT），然后再删下一批。切记，WHERE条件中的列必须有索引，否则BETWEEN查询还是会退化成全表扫描，失去分批的意义。 - 级联清空注意：PostgreSQL的
TRUNCATE ... CASCADE语法非常强大，可以一键清空主表及其所有外键关联表。但威力越大，责任越大，执行前务必再三确认级联关系是否符合预期，因为它不会给出二次确认提示，数据说没就没了。
最后，一个极易被忽略但非常重要的收尾步骤：无论你采用哪种方式清空了表，之后都记得更新一下表的统计信息。 在MySQL中执行ANALYZE TABLE，在PostgreSQL中执行ANALYZE。如果不这样做，查询优化器还会依据清空前的旧统计信息来制定执行计划，很可能导致后续的查询性能低下，走了冤枉路。
