应使用 truncate table #t 重置局部临时表的 identity 列，而非 delete；需先判断表存在性，如 if object_id('tempdb..#t') is not null truncate table #t；truncate 在 tempdb 中不可回滚，全局临时表 ##t 不适用此法。
SQL Server 存储过程中清空临时表不能只用 DELETE FROM #t
局部临时表（#t）在存储过程退出时会自动销毁，但若过程内多次执行、或需提前释放数据占用，仅靠 DELETE FROM #t 无法重置自增列（如 ID INT IDENTITY(1,1)），新插入记录仍从原最大值继续编号。这不是 bug，是 SQL Server 的设计行为：DELETE 只删行，不碰 IDENTITY 计数器。
实操建议：
-
TRUNCATE TABLE #t才能真正重置IDENTITY值——但它在存储过程中对局部临时表有效，且无需担心外键（临时表默认无外键约束） - 如果表定义含
IDENTITY列，必须用TRUNCATE；若只是普通列，DELETE也可，但没优势 - 别在
TRUNCATE后加DBCC CHECKIDENT('#t', RESEED, 1)——多余，TRUNCATE已做完这事
先判断临时表是否存在再 TRUNCATE，否则报错中断流程
存储过程可能被重复调用，或分支逻辑中临时表未必已创建。直接 TRUNCATE TABLE #t 遇到不存在的表会抛出错误 Msg 3701, Level 11, State 5，导致后续语句不执行。
安全写法只有两种：
- SQL Server 2016+：用
DROP TABLE IF EXISTS #t+CREATE TABLE #t (...)重建——适合结构固定、可接受重建开销的场景 - 所有版本通用：用
IF OBJECT_ID('tempdb..#t') IS NOT NULL TRUNCATE TABLE #t;——轻量、不重建、保留原结构和索引
注意 OBJECT_ID('tempdb..#t') 中的 tempdb.. 不可省略，否则查不到临时表。
TRUNCATE TABLE #t 在事务中不可回滚，但临时表本身不受事务保护
很多人以为 TRUNCATE 是 DDL 就一定不能回滚，其实不然：在用户数据库中，TRUNCATE 在显式事务里可以回滚；但在 tempdb 上，SQL Server 对临时表的 TRUNCATE 操作不记日志，也不支持回滚——即使你写了 BEGIN TRAN，执行后 ROLLBACK 也无法恢复数据。
这意味着：
- 不要依赖事务来回滚临时表清空操作；它本就是“即刻生效”
- 若需可逆，改用
DELETE FROM #t（但放弃重置IDENTITY） - 临时表数据本就不该承载业务一致性要求，这个限制反而符合其设计定位
全局临时表 ##t 不能用 TRUNCATE 跨会话重置
全局临时表（##t）生命周期由“最后一个引用它的会话”决定，TRUNCATE TABLE ##t 在当前会话执行后，其他会话仍能看到该表（只是空的），且它们插入数据时 IDENTITY 仍从上次最大值继续——因为 TRUNCATE 不影响其他会话的计数器视图。
所以：
- 避免在存储过程中操作
##t的IDENTITY重置需求；它天生不适合多会话共享自增状态 - 真要跨会话统一清空+重置，只能靠应用层协调，或改用持久表 + 显式
DBCC CHECKIDENT - 绝大多数场景下，坚持用局部临时表
#t，问题就不存在了
IDENTITY 重置只对当前会话生效，且仅当使用 TRUNCATE 时才发生；任何试图在存储过程中用 DBCC CHECKIDENT 手动干预 #t 的做法，都是画蛇添足。
