用临时表备份是为单次DML操作提供轻量、快速、事务内可控的回滚依据，而非替代数据库备份；需严格同步WHERE条件、显式建表+INSERT、同一事务执行，并用UPDATE/MERGE安全还原。
为什么要用临时表做修改前备份，而不是直接备份整表
直接 SELECT INTO 或 BACKUP TABLE（SQL Server 不支持该语法）成本太高，尤其对大表；而临时表只存即将被改的数据，轻量、快、事务内可控。关键在于：它不是替代数据库备份，而是为单次 DML 操作提供回滚依据——比如你 UPDATE 错了 WHERE 条件，能立刻从临时表还原那几行。
常见错误现象：SELECT * INTO #backup FROM dbo.orders WHERE status = 'pending' 后直接 UPDATE，结果发现条件写成 status = 'shipped'，但 #backup 里没数据——因为备份和修改的筛选逻辑不一致，必须严格同步。
- 备份语句和后续
UPDATE/DELETE的WHERE条件必须完全一致（建议先写好条件，复制粘贴） - 临时表字段要包含所有可能用于还原的列，包括
IDENTITY列（若需还原主键值） - 用
#backup（本地临时表）即可，不用##backup（全局），避免跨会话干扰
如何正确创建带结构和数据的临时表备份
别用 SELECT INTO 直接建表——它不复制 IDENTITY、DEFAULT、NOT NULL 约束，还原时可能失败。应该先用 CREATE TABLE #backup AS ... 语法？不对，SQL Server 不支持。正确做法是显式建表 + INSERT。
实操建议：
- 用
SELECT TOP 0 *+INTO #backup快速克隆结构（含NULL属性），再INSERT INTO #backup SELECT ... - 如果原表有
IDENTITY列且你要保留原始值，执行SET IDENTITY_INSERT #backup ON再插入 - 务必在同一个显式事务中完成：建表 → 插入 → 修改，否则事务中断后临时表自动销毁，备份就丢了
示例：
BEGIN TRAN; SELECT TOP 0 * INTO #backup FROM dbo.users; SET IDENTITY_INSERT #backup ON; INSERT INTO #backup SELECT * FROM dbo.users WHERE user_id IN (101, 102, 103); SET IDENTITY_INSERT #backup OFF; UPDATE dbo.users SET email = 'new@x.com' WHERE user_id IN (101, 102, 103); -- 若出错，执行：UPDATE u SET u.email = b.email FROM dbo.users u INNER JOIN #backup b ON u.user_id = b.user_id;
还原时为什么不能直接用 INSERT OVERWRITE 或 TRUNCATE+INSERT
SQL Server 没有 INSERT OVERWRITE；TRUNCATE + INSERT 会重置 IDENTITY 种子，且破坏外键引用完整性（即使没开级联）。真正安全的还原方式是逐行 UPDATE 或 MERGE，匹配主键或唯一约束。
容易踩的坑：
- 还原语句漏掉
WHERE条件，把整个表都刷成备份里的旧值 - 临时表字段顺序和原表不一致，导致
UPDATE ... SET (a,b) = (SELECT a,b...)列错位 - 没考虑并发：别人同时改了同一行，你的还原会覆盖他们的变更——这不是临时表的问题，而是业务层没加锁或版本控制
临时表备份不适合哪些场景
它解决不了跨事务、跨会话、跨时间点的数据恢复。比如你早上 9 点备份，下午 3 点才发现上午的误操作，#backup 早没了。
明确不适用的情况：
- 需要恢复到某个时间点（用
RESTORE LOG或时点恢复） - 修改涉及多个关联表，且存在外键级联动作（临时表无法捕获约束触发行为）
- 表数据量极大（>500 万行），且只改少量行——此时
SELECT INTO备份反而比临时表更省内存（因临时表在tempdb分配空间，可能引发争用）
最常被忽略的一点：临时表本身不记录操作日志细节，它只存“快照”。如果你需要知道“谁、什么时候、为什么改”，得靠 CHANGE TRACKING 或自建审计表，而不是依赖 #backup。
