SQL触发器根本不会响应存储过程内部对临时表的任何操作，因其仅监听永久表的DML事件，而临时表不注册于系统元数据、不生成持久化定义、不产生事务日志记录，故从解析到执行全程被触发器引擎忽略。
SQL触发器根本不会响应存储过程内部对临时表的任何操作——这不是遗漏或配置问题，而是设计上就不可能发生。
触发器只监听永久表的DML，不感知临时表生命周期
SQL Server 和 MySQL 的触发器机制都只绑定在数据库元数据中注册的**永久表（user table）** 上。临时表（#temp 或 ##temp）不进系统表 sys.tables，也不生成持久化的对象定义，因此触发器引擎在解析、注册、匹配阶段就直接跳过它们。
- 你在存储过程中执行
INSERT INTO #log VALUES (...)，这条语句不会走触发器路径，连“是否该触发”这一步都不会进入判断逻辑 -
SELECT * FROM #temp、UPDATE #temp SET x=1、DROP TABLE #temp全部属于会话内存操作，不产生事务日志中的 DML 记录，自然无从触发 - 哪怕你用
EXEC sp_executesql N'INSERT INTO #t ...'动态执行，只要目标是临时表，依然不触发——触发器不解析动态 SQL 的语义，只监控实际提交到永久表的语句
为什么“在触发器里调用存储过程”也捕获不到它的临时表行为
触发器可以调用存储过程，但这个调用只是控制流转移，不是 DML 事件源。存储过程内部的所有操作，包括它创建/读写/删除 #temp，都发生在触发器执行上下文中，但它们本身不构成新的 DML 触发点。
- 触发器执行时，
@@NESTLEVEL+1；它里面EXEC proc_x，@@NESTLEVEL再+1；但 proc_x 里的INSERT INTO #t不会让嵌套层级再+1，也不会激活任何新触发器 - 错误日志里查不到相关记录，
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是语句一部分，不是独立操作，也不触发额外触发器 - 日志表
audit_log自身有触发器，而你恰好在存储过程中往它插数据——那触发的是audit_log的触发器，和原始临时表毫无关系
真正要跟踪临时表使用痕迹，得换思路：用 sys.dm_exec_requests + sys.dm_exec_sql_text 抓正在运行的语句文本，或在存储过程开头加 INSERT INTO debug_log(...) 手动埋点。依赖触发器，永远得不到答案。
