sql临时表分三类：#temp会话级自动销毁、##global_temp全局共享最后引用断连才删、_tmp等伪临时表实为普通表需truncate或重命名清理。
直接删表比清空更快，但必须确认是否真能删——很多“临时表”其实是业务逻辑依赖的中间状态表，不是#temp。
先分清这是哪种“临时中间表”
SQL里叫“临时表”的东西，实际有三类，清理方式完全不同：
-
#temp（会话级临时表）：只在当前连接可见，连接断开自动销毁。不用手动清理，但存储过程中必须显式DROP TABLE #temp，否则分支未执行到就残留，下次执行报“对象已存在” -
##global_temp（全局临时表）：所有会话可见，最后引用它的连接断开才删。极少用，容易被误当成持久表，禁止在高频存储过程中使用 - 普通表名带
_tmp、_stg、staging_等前缀的“伪临时表”：本质是普通表，DROP会锁元数据、阻塞其他查询，数亿行下应优先TRUNCATE
TRUNCATE 比 DELETE 快的根本原因
TRUNCATE 不走事务日志逐行记录，而是直接释放数据页，不触发触发器，也不检查外键——但它要求你有DROP权限，且表不能被外键引用。
- 对数亿行表，
DELETE FROM staging_orders可能跑几小时，还占满ib_logfile和undo log -
TRUNCATE TABLE staging_orders通常在毫秒级完成，即使表有100个索引也无感 - MySQL 8.0+ 和 SQL Server 支持
TRUNCATE ... RESTART IDENTITY，PostgreSQL 需加RESTART IDENTITY显式重置序列
删不掉时的兜底方案：分区交换或重命名
如果表被外键引用、或应用代码硬编码了表名无法TRUNCATE，就别硬刚DELETE。用结构操作绕过：
- MySQL / PostgreSQL：新建空表
staging_orders_new，RENAME TABLE staging_orders TO staging_orders_bak, staging_orders_new TO staging_orders—— 原子操作，毫秒级 - SQL Server：用分区切换（
SWITCH PARTITION），把原表整个分区切到空表，再DROP空分区表 - 所有场景下，别在凌晨跑
DELETE WHERE 1=1+COMMIT分批删：每批都写日志、占锁、可能被长事务阻塞，总耗时反而更不可控
真正容易被忽略的点
清理动作本身很快，但后续影响常被忽视：
-
TRUNCATE后，SQL Server 的统计信息不会自动更新，下次查询可能沿用旧基数估算，导致执行计划退化；需手动UPDATE STATISTICS staging_orders - MySQL 中，
TRUNCATE会重置AUTO_INCREMENT值，如果下游依赖自增ID连续性，得提前记下最大ID再用ALTER TABLE ... AUTO_INCREMENT = N - 所有数据库中，
TRUNCATE无法回滚（DDL），一旦执行就不可逆——生产环境务必加BEGIN TRAN包裹（SQL Server）或在低峰期人工确认
