全局临时表不能用于多用户并发场景，因其生命周期依赖会话存活与引用计数，无事务隔离和锁保护，易导致对象消失、结构覆盖及竞态错误。
全局临时表不是“多用户共享”的安全方案
直接说结论：##TempTable 不能用于解决多用户并发登录、状态同步等场景——它看似“全局”，实则生命周期极短、可见性极不稳定，反而比局部临时表更容易引发 Invalid object name 或竞态错误。
为什么##表在多用户下会“突然消失”或“被覆盖”
全局临时表的可见性依赖两个条件同时成立：创建它的会话仍存活 + 至少还有一个其他会话正在引用它。一旦创建者断开（比如 Web 应用释放连接、SSMS 窗口关闭），哪怕其他会话正执行 SELECT * FROM ##LoginStatus，下一次查询就可能报错。
- 常见错误现象：
Invalid object name '##LoginStatus'，尤其在负载均衡或多线程调用时高频出现 - 根本原因：SQL Server 不保证
##表跨会话持久存在；它只做“引用计数”，不提供锁保护或事务语义 - 典型误用：用
##LoginStatus记录用户登录状态，期望所有后续请求都能读取——但第一个用户登录后连接关闭，表即被销毁，第二个用户查不到，第三个用户又重建，造成状态断裂
##表与并发写入冲突的底层机制
多个用户同时执行 CREATE TABLE ##LoginStatus，不会报错，但实际行为是“最后成功创建者胜出”：后创建的会覆盖前一个同名表结构（包括列定义、索引），且已有数据全丢。这不是原子操作，中间状态可被其他会话读到脏数据。
- 没有
CREATE TABLE IF NOT EXISTS ##t语法，必须手动IF OBJECT_ID('tempdb..##LoginStatus') IS NOT NULL DROP TABLE ##LoginStatus - 即使加了判断，两个会话在毫秒级内都通过判断、都执行
CREATE，仍会发生结构覆盖 -
##表写入tempdb，高并发下易触发PAGELATCH_UP等资源争用，比局部临时表更易成为瓶颈
真正需要跨会话共享状态时该怎么做
用 ## 表，等于把业务逻辑绑死在 SQL Server 的会话生命周期和 tempdb 锁机制上——这是最隐蔽也最难调试的耦合点。
- 轻量级登录状态：改用带
SessionID或ConnectionID字段的永久表（如UserSession），配合GETDATE()和心跳更新 - 需强一致性的共享中间结果：走应用层缓存（Redis）或消息队列，避免数据库承担协调职责
- 仅限开发调试：可用
##表临时观察，但绝不上线；生产环境连SELECT INTO ##t都应禁用
真正的复杂点从来不在“怎么建表”，而在于你是否意识到：## 表的“全局”只是幻觉，它的背后没有事务、没有锁、没有清理保障——它只是 tempdb 里一个被引用计数牵着走的裸对象。
