本地临时表（#temp）在存储过程中不可见，因其作用域仅限当前批处理；SQL Server编译时无法解析#temp，导致保存或执行时报错；全局临时表（##temp）虽可用但有并发和残留风险；推荐使用表变量或INSERT...EXEC替代。
存储过程里查不到#temp表：作用域根本不对
本地临时表（#temp）只在**当前会话的当前批处理内可见**，而存储过程默认以独立批处理方式执行——哪怕它和你创建#temp的语句在同一个连接里，只要没显式用GO分隔，SQL Server 仍可能在编译阶段就报“对象名 #temp 无效”。这不是运行时错误，是解析失败。
常见表现：CREATE PROCEDURE 里直接写 SELECT * FROM #temp，保存就报错；或者调用时提示“找不到对象”，哪怕前面刚CREATE TABLE #temp过。
- 根本原因：SQL Server 对存储过程做延迟绑定（deferred name resolution），但仅限于**永久表和全局临时表（
##temp）**，对本地临时表不适用 -
SET NOCOUNT ON不解决这个问题，它只抑制影响行数的消息，和对象可见性无关 - 别指望把
CREATE TABLE #temp和后续查询塞进同一个存储过程里——SQL Server 编译时看不到这个表
改用##temp全局临时表：能用但得小心并发
##temp 表在创建它的会话结束后才销毁，且对其他会话可见（只要还没被删），所以存储过程内部可以安全引用它。但代价是并发风险：
- 多个用户同时执行同一存储过程，可能互相覆盖
##temp中的数据 - 如果存储过程异常退出，
##temp可能残留，下次同名创建会报“对象已存在” - 必须显式加判断：先
IF OBJECT_ID('tempdb..##temp') IS NOT NULL DROP TABLE ##temp - 命名建议带会话标识，比如
##temp_@@SPID，避免冲突
更稳妥的替代方案：表变量或INSERT ... EXEC
如果只是想把存储过程结果暂存再加工，优先考虑这两条路：
- 表变量（
@temp_table）：生命周期绑定到批处理，无命名冲突，适合小数据量（ -
INSERT INTO @table_var EXEC proc_name：把存储过程结果集直接插入表变量，绕过临时表中转。但要求存储过程**不能有动态 SQL、不能有多个结果集、不能有SET NOCOUNT OFF以外的 SET 选项变更** - 若必须用临时表结构，可用
SELECT * INTO #temp FROM (EXEC proc_name) AS t（SQL Server 2016+ 支持），但需确保目标列名明确、类型可推断
为什么SELECT ... INTO #temp 在存储过程中有时也失败
不是所有存储过程都支持 SELECT ... INTO 创建临时表，尤其当：
- 存储过程里嵌套了另一个存储过程，而内层返回了多个结果集（SQL Server 无法确定哪一个是 INTO 的目标）
- 目标数据库兼容级别
-
SELECT中用了ORDER BY但没配TOP或OFFSET，某些版本会拒绝 INTO - 字段名含空格或特殊字符，导致
INTO自动命名失败（如生成[col name]这种非法标识符）
真正难缠的从来不是语法怎么写，而是搞不清 SQL Server 在哪个环节（编译？执行？权限检查？）卡住了临时表——多数时候，问题不在你怎么用，而在你默认它该怎样被识别。
