局部临时表不会跨会话冲突，因其作用域限于当前会话，SQL Server自动附加唯一后缀实现物理隔离；嵌套存储过程中同名临时表互不干扰，由作用域栈管理，退出即自动清理。
局部临时表为什么不会跨会话冲突
因为以 # 开头的临时表作用域严格限定在当前会话（session）内，SQL Server 在内部会自动给它附加唯一后缀（比如 #TempTable__000000000001），不同会话哪怕都写 CREATE TABLE #tmp，实际创建的也是物理隔离的表。这意味着：两个并发执行的存储过程，即使都定义了 #tmp，彼此完全不可见、互不干扰。
同名临时表在嵌套存储过程中是否安全
安全。SQL Server 对局部临时表做了“作用域栈”管理：父存储过程里的 #tmp 和子存储过程中同名的 #tmp 是两个独立对象。子过程创建时，父过程的 #tmp 仍存在但不可访问；子过程退出后，它的 #tmp 自动销毁，父过程的 #tmp 恢复可用。这和变量作用域逻辑一致。
- 不需要手动
DROP TABLE #tmp—— 存储过程退出即自动清理 - 但显式
DROP也没错，尤其在长过程里提前释放空间时有用 - 如果子过程里想“复用”父过程的临时表，不能靠同名，得用表变量或传结构化参数替代
常见错误：把 # 临时表当成全局共享中间表
典型误用是：多个应用线程同时调用同一个存储过程，过程里建了 #Result，然后期望后续另一个查询能读取它——这是行不通的。因为每个连接都是独立会话，#Result 只在当前连接生命周期内有效。一旦连接关闭（比如 Web 请求结束），表就没了。
- 错误现象：
Invalid object name '#Result'，尤其在 SSMS 多窗口测试时容易复现 - 真正需要跨会话共享？改用
##GlobalTemp（但要注意竞态和清理时机）或永久表 + 前缀/会话ID字段 - 高频小数据场景，优先考虑
DECLARE @t TABLE(...)表变量，开销更低、无日志、不参与事务回滚
性能与兼容性需要注意的细节
局部临时表虽然方便，但不是万能缓存。它写入 tempdb，高并发下容易成为瓶颈，尤其当大量过程频繁建/删大临时表时。
-
tempdb文件配置不合理（如单文件、未预分配）会导致allocation contention，表现为大量PAGELATCH_UP等待 - SQL Server 2016+ 支持
CREATE OR ALTER PROCEDURE，但临时表定义本身不受影响——每次执行仍重建 - 避免在循环中反复
CREATE TABLE #t+INSERT，改用一次性建表 +TRUNCATE或表变量更高效 - 如果临时表只读且结构固定，考虑用
SELECT ... INTO #t替代显式CREATE，省去列定义维护
临时表真正的复杂点不在语法，而在你是否清楚它背后绑定的是会话生命周期、tempdb 资源和锁行为——这些看不见的部分，比怎么写 CREATE TABLE #x 更容易出问题。
