SQL Server本地临时表（#t）生命周期绑定会话而非存储过程，过程执行完仍存在；必须显式DROP才能避免重复创建报错，因同名临时表在会话内不可重定义。
SQL Server 存储过程执行完，#临时表还在，不是 bug，是设计如此
SQL Server 本地临时表（#t）的生命周期绑定在**会话（session）**，而非存储过程作用域。哪怕你在存储过程中 CREATE TABLE #t 再 SELECT * FROM #t，过程一返回，#t 依然存在——只要连接没断，它就一直可查、可改、可重用。这不是“没释放”，而是“不该这时释放”。
为什么调用完存储过程还能查到 #t？
本地临时表的作用域是整个连接，不是单次存储过程调用。常见现象包括：
- 在 SSMS 新建查询窗口执行一次含
CREATE TABLE #tmp的存储过程，再在同一窗口手动SELECT * FROM #tmp，能查到数据 - 用 C# 多次调用同一存储过程，第二次执行时
CREATE TABLE #tmp报错There is already an object named '#tmp' in the database - 在存储过程里反复
CREATE TABLE #t+INSERT INTO #t，不加DROP TABLE #t，后续语句可能因命名冲突失败
根本原因：SQL Server 不允许同名本地临时表在同一个会话中重复创建，且不会在过程退出时自动清理——它等你显式删，或等连接关闭。
SQL Server 和 MySQL 临时表行为的关键差异
对比 MySQL 就容易理解这个设计选择：
- MySQL 的
CREATE TEMPORARY TABLE同样按会话隔离，但很多客户端（如 PHP PDO）默认复用连接，导致“上一次过程留下的#t”被下一次调用撞见；而 SQL Server 的行为更透明：你在哪建的，就在哪能看见 - SQL Server 存储过程内创建的本地临时表，在过程返回后仍保留在当前会话中；MySQL 则没有“过程级自动清理”这回事，两者都依赖会话结束或显式
DROP - 全局临时表（
##t）在 SQL Server 中需所有引用会话都断开才销毁；MySQL 没有直接对应的全局临时表机制
别被“过程执行完毕”误导——T-SQL 层面没有“过程作用域临时表”这种东西。
什么时候必须手动 DROP TABLE #t？
不是“总是要 DROP”，而是以下场景不 Drop 就会出问题：
- 存储过程逻辑中多次尝试
CREATE TABLE #t（比如循环体或条件分支），必须在首次创建前加IF OBJECT_ID('tempdb..#t') IS NOT NULL DROP TABLE #t - 过程里用
SELECT ... INTO #t创建表，后续又想用同样名字重建，不DROP就报错 - 过程嵌套调用：外层过程建了
#t，内层也想建同名#t，SQL Server 不允许（和变量作用域不同） - 调试阶段反复执行同一段脚本，避免手动清空 tempdb 或重启连接
注意：DROP TABLE #t 是安全操作，即使表不存在也不会报错（前提是加了 IF OBJECT_ID 判断）；但不要在错误处理块里盲目 DROP 所有临时表——可能破坏调用方依赖的中间状态。
表变量 vs 本地临时表：何时换用 @t？
如果只是存几行中间结果、不需要索引、不参与复杂 JOIN，优先用表变量（@t TABLE(...)）：
- 表变量生命周期严格限制在声明它的批处理/过程内，过程一退出自动消失，不用
DROP - 不生成统计信息，不参与查询优化器的“重编译决策”，适合小数据量、确定性流程
- 不能在
EXEC()或sp_executesql动态 SQL 中直接引用（除非传参），而#t可以跨动态 SQL 访问 - 大数据量时性能通常不如临时表（无统计信息 + 缓冲区分配策略不同）
真正棘手的不是“该不该删”，而是混淆了“过程执行结束”和“会话生命周期结束”。连接不断，#t 就不会走——哪怕你已经调用了十遍存储过程。
