触发器中不能直接查询临时表，因本地临时表#t仅限创建会话和作用域可见，而触发器有独立作用域；应优先使用INSERTED/DELETED伪表获取变更数据，或改用带唯一命名的持久表并严格管理生命周期。
触发器里不能直接查临时表，这是设计限制
SQL Server 的 AFTER 或 INSTEAD OF 触发器运行在事务上下文中，但临时表（#temp）的作用域仅限于创建它的会话+批处理。触发器是隐式调用的独立执行单元，它看不到外部会话创建的 #temp 表——哪怕那个会话就是触发它的客户端。
常见错误现象：Invalid object name '#mydata'. 或查询返回空结果，不是数据没写进去，而是根本不可见。
- 本地临时表
#t只对当前会话、当前作用域（如存储过程内）可见；触发器有自己独立的作用域 - 全局临时表
##t虽然跨会话可见，但需严格管理生命周期，且多个并发操作可能互相干扰 - 表变量
@t TABLE(...)同样不可跨作用域，触发器里查不到外部声明的@t
替代方案：用 INSERTED/DELETED 伪表传递变更数据
绝大多数想“引用临时表数据”的真实需求，其实是想拿到当前 DML 操作涉及的行。SQL Server 触发器天然提供 INSERTED 和 DELETED 两个内存驻留的伪表，它们结构与原表一致，内容就是本次 INSERT/UPDATE/DELETE 影响的行。
例如，你想在 UPDATE Orders 时检查新旧价格差是否超阈值：
CREATE TRIGGER tr_check_price_change
ON Orders
AFTER UPDATE
AS
BEGIN
IF EXISTS (
SELECT 1
FROM INSERTED i
JOIN DELETED d ON i.OrderID = d.OrderID
WHERE ABS(i.Price - d.Price) > 100
)
BEGIN
RAISERROR('Price change too large', 16, 1)
ROLLBACK
END
END-
INSERTED包含新值（INSERT或UPDATE后），DELETED包含旧值（UPDATE或DELETE前） - 它们只存在于触发器执行期间，无需显式创建或清理
- 性能好：不走磁盘，无锁竞争，比临时表快得多
真需要跨作用域共享数据？改用持久表 + 清理策略
如果业务逻辑确实要求触发器读取“外部预计算结果”（比如一个批量导入任务先算好校验码存到临时表，再逐条触发更新），必须放弃临时表，改用带命名约定的持久表，并自行控制生命周期。
例如建一张 staging_validation_20240520_123456 表（用时间戳+进程ID保证唯一），插入后由触发器按名查询：
-- 外部脚本中：
SELECT checksum_value INTO staging_validation_20240520_123456
FROM source_data WHERE ...;
<p>-- 触发器内：
DECLARE @tbl_name SYSNAME = 'staging_validation_20240520_123456';
EXEC('SELECT * FROM ' + @tbl_name + ' WHERE id IN (SELECT OrderID FROM INSERTED)');- 表名必须动态拼接，因为触发器无法参数化表名
- 务必在外部脚本结束后立即
DROP TABLE，否则残留表会污染数据库 - 高并发场景下，不同批次需用不同表名，避免冲突
- 注意 SQL 注入风险：表名必须严格校验（只允许字母数字和下划线）
别碰游标 + 临时表组合，这是性能黑洞
有人试图在触发器里用游标遍历 INSERTED，再对每行查一次外部临时表——这会让原本毫秒级的触发器变成秒级甚至超时。触发器应保持轻量，所有复杂逻辑尽量前置到应用层或存储过程中。
- 触发器执行是同步阻塞的，慢=整个 DML 卡住
- 每个触发器调用都新建临时表，IO 和编译开销叠加，容易引发
tempdb争用 - SQL Server 2016+ 对触发器嵌套深度有限制（默认 32 层），嵌套调用临时表操作极易触达上限
真正难处理的是跨会话状态传递，这不是触发器该干的事。把数据准备好、逻辑拆出去，比硬塞进触发器靠谱得多。
