触发器内无法访问外部创建的#temp表，因其作用域隔离且解析阶段即报错；禁止在触发器中创建#temp或##temp表，因ddl日志写入与隐式事务冲突；应使用inserted/deleted伪表获取dml数据。
触发器里查不到#temp表，根本不是权限或语法问题
SQL Server 触发器执行时，会创建一个独立的作用域（batch scope），它和外部会话、存储过程、甚至同一连接中前一条语句的批处理都**不共享局部临时表**。你在触发器外 CREATE TABLE #t，触发器内部执行 SELECT * FROM #t，直接报 Invalid object name '#t'——这不是延迟可见、也不是没提交，而是解析阶段就失败：引擎压根不把触发器当“同一批处理”。
常见误判场景：
- 在存储过程中先建
#t，再执行INSERT INTO real_table触发触发器 → 触发器看不见#t - 用
EXEC sp_executesql N'SELECT * FROM #t'动态执行 → 依然报错，作用域隔离是硬限制 - 加了
TRY...CATCH或IF EXISTS判断 → 解析不过，根本进不了执行逻辑
为什么不能在触发器里 CREATE TABLE #temp？
触发器运行在隐式事务中，而创建本地临时表需向 tempdb 写入元数据和日志记录，这与当前事务上下文冲突。错误信息明确：The current transaction cannot be committed and cannot support operations that write to the log file.
这个限制不是可绕过的配置项，而是 SQL Server 执行模型的底层约束：
-
CREATE TABLE #temp会触发tempdb.sys.tables的 DDL 日志写入 → 不被允许 -
CREATE TABLE ##temp同样失败，因为全局临时表也要写日志，且存在并发污染风险 - 哪怕把
CREATE放在IF分支里、或用动态 SQL 包裹 → 解析阶段即被拦截，不会等到运行时
真正该用 INSERTED/DELETED，而不是临时表
95% 的“想在触发器里读临时表”场景，实际需求只是获取本次 DML 涉及的行。SQL Server 原生提供 INSERTED 和 DELETED 两个伪表，它们：
- 结构自动匹配原表，无需定义
- 只存在于触发器执行期间，不占磁盘、无锁竞争、不用清理
-
INSERTED包含新值（INSERT或UPDATE后），DELETED包含旧值（UPDATE或DELETE前） - 性能远高于临时表，尤其在高并发更新时
例如校验价格变更是否超阈值，直接写：
IF EXISTS (
SELECT 1 FROM INSERTED i
JOIN DELETED d ON i.OrderID = d.OrderID
WHERE ABS(i.Price - d.Price) > 100
)
RAISERROR('Price change too large', 16, 1)
真要跨作用域传数据，持久表 + 命名规范比##temp更可控
如果业务逻辑确实要求触发器读取“外部预计算结果”（比如批量导入后校验码已算好），必须放弃临时表思路。用带唯一命名的持久表替代：
- 表名嵌入时间戳+进程标识，如
staging_validation_20260905_123456 - 插入完成后，触发器按确定名称查询：
SELECT * FROM staging_validation_20260905_123456 - 必须配套清理逻辑：任务结束或触发器执行完后，显式
DROP TABLE，不能依赖超时或重启 - 避免用
##temp：即使加了OBJECT_ID('tempdb..##t') IS NOT NULL判断，在高并发下仍可能因@@SPID碰撞导致数据错乱
最常被忽略的一点：临时表不是通信管道，而是批处理内的临时容器。试图用它桥接触发器和主语句，本质是在对抗 SQL Server 的执行模型边界。
