SQL触发器根本不会识别临时表（#temp或##temp）上的任何数据变更，因其不进系统元数据、不记事务日志、不生成持久对象定义，引擎连“是否触发”都不会判断；触发器仅响应永久表的DML事件。
SQL触发器根本不会识别临时表（#temp 或 ##temp）上的任何数据变更——这不是配置问题，而是机制上不可能发生。触发器只响应永久表的 DML 事件，而临时表不进系统元数据、不记事务日志、不生成持久对象定义，引擎连“要不要触发”这一步都不会执行。
为什么触发器对 #temp 操作完全无感
临时表操作（INSERT INTO #t、UPDATE #t、DROP TABLE #t）全程在会话内存中完成，不写入 tempdb.sys.tables，也不产生事务日志中的 DML 记录。触发器引擎依赖系统元数据注册和日志流捕获来触发，这两样临时表全都不提供。
- 哪怕你在存储过程中用
EXEC sp_executesql N'INSERT INTO #t ...'动态执行，目标仍是临时表 → 不触发 - 在触发器里调用存储过程，该过程内部操作
#temp→ 不构成新 DML 事件源，只是控制流转移 - 错误日志查不到记录，
sys.dm_exec_trigger_stats的exec_count完全不变 —— 因为压根没“触发”这件事
误以为“捕获到了”的典型错觉场景
看起来像触发器响应了临时表操作，实际是其他逻辑在起作用：
- 你在触发器里写
INSERT INTO audit_log SELECT * FROM #temp→ 只是把当前会话已有的数据抄一遍，和触发时机无关 - 存储过程结尾执行
INSERT INTO real_table SELECT * FROM #temp→ 真正触发的是这句对永久表的INSERT，不是前面的临时表操作 - 用
OUTPUT子句把 DML 结果输出到#temp→OUTPUT是语句的一部分，不是独立操作，也不触发额外触发器
想在触发器中安全使用临时数据，该怎么做
如果目标是让触发器逻辑能访问变更数据，别碰 #temp，优先走原生机制；如果必须中转中间数据，##temp 可行但风险高，得手动控生命周期：
- 首选
inserted/deleted：它们是触发器内置的内存行集，免建表、免清理、事务一致。注意不能直接在子查询中多次引用，也不能当 CTE 源 - 改用
OUTPUT子句：把变更结果直接导向表变量或永久表，避免中间落盘 - 若坚持用
##temp：建表前先IF OBJECT_ID('tempdb..##mydata') IS NOT NULL DROP TABLE ##mydata；表名务必带@@SPID或NEWID()防撞名；插入后立即建索引；所有读写完成后立刻DROP TABLE ##mydata，别等触发器末尾
最常被忽略的点：临时表不是数据载体，而是作用域容器。它的存在意义是简化批处理逻辑，不是跨上下文通信。试图用它桥接触发器和主语句，本质上是在对抗 SQL Server 的执行模型设计边界。
