最可靠方式是用 OBJECT_ID('tempdb..#table') 判断本地临时表是否存在，返回非空INT表示存在，NULL表示不存在；必须写全路径 'tempdb..#table'，不可省略或误写为 'dbo.#table'。
用 OBJECT_ID('tempdb..#table') 判断本地临时表是否存在
SQL Server 中判断本地临时表（#table）是否存在的最可靠方式，是查 OBJECT_ID('tempdb..#table') 是否非空。它直接访问 tempdb 的对象元数据，不依赖视图稳定性，兼容 SQL Server 2005 及以上所有版本。
注意必须写全路径 'tempdb..#table' ——省略 tempdb.. 会查当前数据库，永远返回 NULL；写成 'dbo.#table' 或 'tempdb.dbo.#table' 也不对，因为临时表没有 schema 绑定，双点（..）表示“默认 schema”，这才是正确语法。
-
OBJECT_ID()返回INT（对象 ID）表示存在，NULL表示不存在 - 第二个参数（如
'U'）可加可不加：加了能限定类型为用户表，但临时表类型始终是'U'，不加也无误 - 不要用
IF EXISTS (SELECT ... FROM tempdb.sys.tables)：这个视图在某些低版本或特定配置下可能不暴露本地临时表
在存储过程中安全删除前必须先判断
直接写 DROP TABLE #t 在临时表不存在时会报错：Cannot drop the table '#t', because it does not exist or you do not have permission. 这会让整个存储过程中断，尤其在循环、重试逻辑里很危险。
所以标准写法是包裹在 IF 块里：
IF OBJECT_ID('tempdb..#MyTemp') IS NOT NULL
DROP TABLE #MyTemp;
如果你用的是 SQL Server 2016+，可以改用更简洁的 DROP TABLE IF EXISTS：
DROP TABLE IF EXISTS #MyTemp;
- 该语法内部已做存在性检查，不会报错，但要注意它只支持 2016 及以上版本，老环境会直接语法报错
- 不能用于全局临时表（
##table）的跨会话竞争场景——IF EXISTS检查和DROP不是原子操作，两个会话可能同时通过检查再同时DROP，但实际只删一次，无害 - 别在同一个批处理里混用
CREATE TABLE #t和后续对#t的引用而不加GO：如果前面有DROP+CREATE+SELECT，且没用GO分隔，SQL Server 会在编译阶段就校验所有列名，导致新增字段后SELECT报“无效列”
区分本地临时表和全局临时表的检查逻辑
本地临时表（#name）只在当前会话可见，检查用 OBJECT_ID('tempdb..#name') 即可；全局临时表（##name）则需注意：它被多个会话共享，OBJECT_ID('tempdb..##name') 在任意会话中都能查到，只要它还活着。
但问题在于：你无法仅凭 OBJECT_ID 判断这个 ##name 是不是“你创建的”——它可能是别人建的。所以对全局临时表，通常不建议“存在即删”，除非你明确控制生命周期。
- 检查全局临时表存在性同样用
OBJECT_ID('tempdb..##name')，逻辑一致 - 删除时也用相同语法：
DROP TABLE ##name，但它不会立即消失，只减少引用计数 - 若存储过程中要确保独占一个临时表名，优先用本地临时表（
#name），避免全局临时表的并发干扰
存储过程内临时表的生命周期陷阱
很多人以为“存储过程结束 = 临时表自动清理 = 不用管”，这没错，但容易忽略嵌套调用场景：如果 A 存储过程里建了 #t，又调用了 B 存储过程，B 里也试图建 #t，就会报错 There is already an object named '#t' in the database.
这时候不能靠“自动清理”，必须在 B 开头显式判断并删掉已存在的同名临时表——哪怕它其实是 A 创建的。因为本地临时表在同一会话内是全局可见的（不是作用域隔离的）。
- 临时表在**同一会话内所有嵌套层级都可见**，不是“子过程私有”
- 因此任何可能被复用或嵌套调用的存储过程，开头都应加
IF OBJECT_ID(...) IS NOT NULL DROP TABLE - 不要依赖“会话断开才删”，长连接、连接池环境下，临时表可能残留数小时，占用 tempdb 资源
OBJECT_ID 行为。 
