全局临时表（##temp）在sql server中并非真正稳定共享，其存在依赖创建会话存活且至少一个会话正在引用，引用计数归零即被立即删除，无事务保障、无原子建表机制，高并发下易发生覆盖、脏读与闩锁争用。
全局临时表在存储过程中会“突然消失”
根本不是稳定性问题，是 SQL Server 对 ##temp 的生命周期管理机制决定的：它只在**创建它的会话存活 + 至少有一个其他会话正在引用**时才存在。一旦创建者断开（比如 Web 应用释放连接池中的连接、SSMS 窗口关闭），哪怕另一个会话正执行 SELECT * FROM ##temp，下一次查询就大概率报 Invalid object name '##temp'。
常见于负载均衡或短连接场景：用户 A 登录后创建 ##LoginStatus 并断开，用户 B 查询时报错；用户 C 再次创建，又覆盖结构——状态链断裂，且无法预测。
- 没有事务保障，不参与锁机制，
##temp上的读写完全裸奔 - 引用计数清零即删表，SQL Server 不做任何等待或重试
-
IF OBJECT_ID('tempdb..##temp') IS NOT NULL只能判断“此刻是否存在”，不能保证“下一毫秒还存在”
多个会话并发 CREATE TABLE ##temp 会互相覆盖
SQL Server 不提供原子性建表保护，也没有 CREATE TABLE IF NOT EXISTS ##t 语法。两个会话几乎同时通过 IF OBJECT_ID 判断后执行 CREATE TABLE ##temp，结果是后执行者胜出：前一个表被删、结构重置、所有数据丢失，且中间状态可能被其他会话读到脏数据。
- 即使加了
DROP TABLE前置判断，也无法避免毫秒级竞态 - 列定义、索引、约束全被覆盖，不是追加或合并
- 高并发下
tempdb的PAGELATCH_UP等闩锁争用会显著上升，比局部临时表更易成为瓶颈
为什么 SET NOCOUNT ON 或延迟编译都救不了 ##temp
SET NOCOUNT ON 只抑制影响行数消息，和对象可见性无关；而 SQL Server 的延迟绑定（deferred name resolution）仅适用于永久表和 ##temp，但它解决不了生命周期问题——编译能过，运行时照样崩。
- 存储过程里写
SELECT * FROM ##temp能保存成功，不代表调用时一定成功 - 错误发生在运行时，不是解析期，所以静态检查或语法验证完全无效
- 调试时看到“表存在”，上线后因连接复用/超时/池回收导致行为不一致，极难复现
真正需要跨会话共享时该用什么替代
把业务状态逻辑绑死在 ##temp 上，等于把可靠性押注在 SQL Server 的会话管理和 tempdb 锁机制上——这是最隐蔽也最难调试的耦合点。
- 轻量状态（如登录标记）：用带
SessionID字段的永久表 +GETDATE()心跳更新 - 强一致性中间结果：走应用层缓存（Redis）或消息队列，数据库只负责最终落库
- 纯调试用途：可临时用
##temp观察，但禁止出现在生产存储过程体中
复杂点从来不在“怎么建表”，而在于你是否意识到：##temp 的“全局”只是幻觉，它背后没有事务、没有锁、没有清理保障，只是 tempdb 里一个靠引用计数苟延残喘的临时对象。
