兄弟，我太懂这种摸不着头脑的感觉了——明明确认临时表不存在，却蹦出“已存在”的报错，尤其是在带游标和UNION的存储过程里，很容易踩SQL Server编译和会话机制的小坑。结合你的场景，给你几个针对性的排查和解决方向：

1. 先解决编译阶段的对象解析冲突 #

SQL Server编译存储过程时，会提前扫描所有对象引用，包括临时表。如果用SELECT ... INTO #TempTable这种运行时创建表的方式，加上UNION的存在，编译引擎可能会误判表已被定义，直接抛出“已存在”的错误。

解决办法：显式先创建临时表，再插入数据

-- 先判断并清理可能残留的临时表
IF OBJECT_ID('tempdb..#MyResult') IS NOT NULL
    DROP TABLE #MyResult

-- 显式定义临时表结构
CREATE TABLE #MyResult (
    Col1 INT,
    Col2 VARCHAR(100),
    Col3 DATETIME
)

-- 再执行带UNION的查询插入数据
INSERT INTO #MyResult
SELECT Col1, Col2, Col3 FROM TableA WHERE Condition1
UNION
SELECT Col1, Col2, Col3 FROM TableB WHERE Condition2

-- 后续游标逻辑基于已创建的临时表
DECLARE @Col1 INT
DECLARE resultCursor CURSOR FOR SELECT Col1 FROM #MyResult
OPEN resultCursor
FETCH NEXT FROM resultCursor INTO @Col1
-- ... 你的游标处理逻辑

2. 排查会话级临时表的残留问题 #

本地临时表（#开头）是会话级的，如果你的测试会话之前执行过失败的存储过程，临时表可能没被自动清理，导致再次执行时冲突。上面代码里的IF OBJECT_ID('tempdb..#MyResult') IS NOT NULL DROP TABLE就是用来解决这个问题的，每次执行前先清掉残留。

3. 权限问题的细节排查 #

虽然你确认权限没问题，但还是要注意两个点：

• 执行存储过程的账号是否有CREATE TABLE权限在tempdb库中？默认普通账号是有的，但如果是受限账号或用了EXECUTE AS子句切换身份，可能会被限制。可以用下面的语句检查：

  USE tempdb
  EXEC sp_helprotect @username = '你的执行账号', @objname = 'sys.tables', @grantor = 'dbo'
  

• 如果存储过程是用WITH EXECUTE AS '某个账号'定义的，要确认这个账号的权限是否足够操作临时表。

4. 先单独验证UNION查询的正确性 #

有时候UNION的两个查询列数、数据类型不匹配，会触发奇怪的错误提示，看起来像是临时表的问题，但实际是UNION本身的语法错误。先把你的UNION查询单独拿出来执行，确保能正常返回结果，再放进存储过程里。

内容的提问来源于stack exchange，提问作者mattgcon