局部临时表（#开头）不会重名冲突，因sql server为每个会话的同名#t自动附加唯一后缀，物理隔离；嵌套存储过程中同名局部临时表安全，依赖作用域栈管理，父、子过程的#t互不干扰且自动销毁。
局部临时表（以 # 开头）本身不会重名冲突，问题不在命名，而在你误用了它的作用域规则。
为什么 CREATE TABLE #t 在并发调用时不会报“对象名已存在”？
SQL Server 对每个会话中同名的 #t 都会自动附加唯一后缀（如 #t__00000001、#t__00000002），物理上是完全隔离的表。哪怕 100 个连接同时执行同一段存储过程，都包含 CREATE TABLE #t (...)，也不会报错——因为它们根本不是同一个对象。
常见错误现象其实是：Invalid object name '#t'，这往往发生在：
- 试图在存储过程外部（比如 SSMS 新建查询窗口）访问过程内创建的
#t - 在动态 SQL 中漏写
EXEC或未用sp_executesql正确传递上下文 - 嵌套过程中误以为子过程能直接读父过程的
#t（实际不可见，需显式传参或改用表变量）
嵌套存储过程中同名临时表是否安全？
安全，但必须理解作用域栈行为：
- 父过程创建
#data→ 子过程也能执行CREATE TABLE #data，两者互不干扰 - 子过程内无法 SELECT 父过程的
#data，哪怕名字一样 - 子过程退出后，它的
#data自动销毁，父过程的#data恢复可访问 - 不需要手动
DROP TABLE #data，但若过程很长、临时表很大，提前DROP可释放 tempdb 空间
真正容易踩坑的“重名”场景有哪些？
所谓“重名冲突”，90% 是开发者混淆了以下三类对象：
-
##global_temp：全局临时表，所有会话可见，高并发下极易因竞态导致数据错乱，除非真需要跨会话共享，否则别用 - 永久表（如
dbo.TempResult）：多个存储过程硬编码写入同一张永久表，没加会话 ID 或时间戳前缀，造成数据覆盖 - 表变量
@t和临时表#t混用：表变量不写入 tempdb 日志、无统计信息，大数据量时性能反而更差，别只因“名字短”就默认选它
典型误用：INSERT INTO #Result SELECT ... 后，在另一个独立查询里直接 SELECT * FROM #Result —— 这必然失败，因为那个查询属于新会话。
该用什么替代“想让多个过程共用一张临时表”的想法？
临时表天生不是为跨会话/跨过程共享设计的。真有这类需求，按优先级选：
- 结构固定、数据量小（DECLARE @t TABLE(...)，开销更低，且可在同一存储过程中被多处引用
- 需跨过程传递中间结果 → 用表值参数（Table-Valued Parameter），把数据作为参数传入子过程
- 必须跨会话且实时性要求不高 → 用带会话标识的永久表，如
TempResult_@SessionId，配合清理逻辑 - 绝对避免：在循环里反复
CREATE TABLE #t+INSERT，应改为一次性建表 +TRUNCATE复用
临时表真正的复杂点不在语法，而在于你是否清楚它背后绑定的是会话生命周期、tempdb 资源争用和锁行为——这些看不见的部分，比怎么写 CREATE TABLE #x 更容易出问题。
