应使用 object_id('tempdb..#t') 判断本地临时表是否存在，因其能准确解析系统生成的带随机后缀的临时表名，而 sys.tables 查询或省略 tempdb.. 前缀均不可靠；判断后须显式 drop table #t，否则重复执行会报错。
存储过程中判断本地临时表是否存在
在存储过程里重复执行建表逻辑时，不加判断直接 CREATE TABLE #t 会报错：There is already an object named '#t' in the database。根本原因是本地临时表作用域虽限于当前会话，但在同一存储过程多次调用（比如递归、循环或重入）时，前一次创建的 #t 可能尚未释放——尤其当存储过程内含嵌套批处理（如 EXEC() 或动态 SQL）时，#t 的生命周期可能被意外延长。
正确做法是始终用 OBJECT_ID('tempdb..#t') 判断：
-
OBJECT_ID()第一个参数必须写全路径'tempdb..#t'，漏掉tempdb..前缀会导致查不到（即使表存在） - 不能用
sysobjects或sys.tables直接查，因为本地临时表名在tempdb中被系统追加了随机后缀（如#t____000000000001），你写的#t并不等于实际对象名 - 判断后必须显式
DROP TABLE #t，不能依赖“自动销毁”，否则下次执行仍会冲突
示例：
IF OBJECT_ID('tempdb..#user_log') IS NOT NULL
DROP TABLE #user_log;
CREATE TABLE #user_log (id INT, op_time DATETIME);
全局临时表的判断逻辑完全不同
全局临时表（##t）虽然也存于 tempdb，但它的可见性跨会话，生命周期由最后一个引用它的连接决定。这意味着：即使你在存储过程中 DROP TABLE ##t，别的会话仍可能正在读它，强行删会报错 Cannot drop the table '##t', because it does not exist or you do not have permission —— 实际上是被其他会话锁住了。
所以对 ##t，要改用更保守的判断方式：
- 依然用
OBJECT_ID('tempdb..##t')，这是唯一兼容所有 SQL Server 版本的可靠方法 - 避免在生产存储过程中依赖
##t，尤其高并发场景下极易因竞争导致不可预期行为 - 如果必须用，建议加
TRY...CATCH包裹DROP，忽略删除失败（只要后续CREATE不报错即可）
示例：
BEGIN TRY
IF OBJECT_ID('tempdb..##shared_cache') IS NOT NULL
DROP TABLE ##shared_cache;
END TRY
BEGIN CATCH END CATCH;
CREATE TABLE ##shared_cache (key VARCHAR(50), val SQL_VARIANT);
动态创建临时表时的常见陷阱
用 EXEC('CREATE TABLE #t ...') 动态建临时表后，该表只在动态 SQL 所在批处理内有效，退出后立即消失。也就是说，后续语句无法访问这个 #t，哪怕在同一存储过程中。
解决办法只有两个：
- 把所有依赖该临时表的操作（
INSERT、SELECT）全部塞进同一段动态 SQL 字符串里 - 改用表变量（
@t TABLE(...)），它支持在存储过程中跨语句使用，且无需判断是否存在 - 如果结构不确定，优先考虑
SELECT ... INTO #t，它会自动建表且隐式覆盖同名表（但注意：若#t已存在，SELECT INTO会报错，所以仍需先DROP）
为什么不能用 EXISTS(SELECT ...) 查临时表
有人尝试这样写：IF EXISTS(SELECT * FROM tempdb.sys.tables WHERE name LIKE '#t%')，看起来直观，但问题很大：
-
tempdb.sys.tables中的name是系统生成的完整名（带后缀），不是你写的#t，LIKE '#t%'可能误匹配其他临时表 - 不同 SQL Server 版本中，临时表在
sys.tables中的可见性不一致（例如某些版本对非当前会话的本地临时表不可见） -
OBJECT_ID('tempdb..#t')是 SQL Server 内部专为此设计的函数，它自动处理名称解析和作用域过滤，稳定且高效
记住：只要涉及临时表存在性判断，无条件信任 OBJECT_ID('tempdb..<i>表名</i>')，其他路都绕远且不可靠。
