SQL Server触发器中不可创建本地临时表#temp，因隐式事务禁止日志写入；应改用表变量@table，但需注意其无统计信息、不支持非聚集索引及作用域限制。
SQL Server 触发器里建 #temp 表直接报错
SQL Server 触发器中执行 CREATE TABLE #temp 会抛出错误：The current transaction cannot be committed and cannot support operations that write to the log file.。根本原因是触发器运行在隐式事务中，而本地临时表的创建会触发日志写入操作，与触发器事务上下文冲突。
这不是语法写错了，也不是权限问题，是 SQL Server 引擎层面的限制。哪怕你把 CREATE TABLE #temp 放在 IF 分支里、或加了 TRY...CATCH，照样报错。
- 临时表（
#temp）依赖 tempdb 的元数据变更和日志记录，触发器不允许这种“副作用” - 表变量（
@table）不写日志、不生成统计信息、生命周期绑定在批处理内，正好绕过限制 - 全局临时表（
##temp）也不行——它同样要写 tempdb 日志，且存在并发污染风险
用 @table 替代 #temp 的实操要点
表变量不是万能缓存，它和临时表在行为上差异明显，硬替换容易翻车。
- 必须显式声明结构，不能用
SELECT * INTO @t FROM ...—— 这句语法非法 - 不支持非聚集索引（SQL Server 2014+ 可建主键/唯一约束，但无法手动加
NONCLUSTERED） - 无统计信息 → 查询优化器默认按 1 行估算，大结果集（>100 行）时执行计划可能严重劣化
- 作用域仅限当前批处理，跨
EXEC(@sql)或动态 SQL 不可见，需改用字符串拼接或临时表 + EXECUTE AS 绕过（但又回到原问题）
示例：正确写法
DECLARE @changed_ids TABLE (id INT PRIMARY KEY); INSERT INTO @changed_ids SELECT id FROM inserted WHERE status = 'pending'; UPDATE t SET processed = 1 FROM orders t INNER JOIN @changed_ids c ON t.id = c.id;
当需要索引或 >1k 行中间数据时怎么办
表变量撑不住，又不能用临时表？得换思路：把“中间值传递”从触发器里剥离出来。
- 改用
AFTER INSERT/UPDATE触发器 +INSERTED和DELETED逻辑表直接关联更新，避免落地中间集合 - 对复杂聚合逻辑，把核心计算下推到函数（
SCHEMABINDING函数可内联），再在触发器里调用 - 真需要暂存大量数据？考虑异步方式：触发器只写一条记录到轻量队列表（
trigger_queue），由外部作业轮询处理 - 极少数必须强一致场景，可启用延迟持久化（
DELAYED_DURABILITY = FORCED）并改用内存优化表变量（DECLARE @t TABLE(...) WITH (MEMORY_OPTIMIZED = ON)），但要求数据库兼容级别 ≥ 130 且实例开启相关配置
容易被忽略的兼容性陷阱
看起来只是换个声明方式，但不同版本 SQL Server 对表变量的支持有断层。
- SQL Server 2005–2012：表变量不支持
INDEX约束，也无STATISTICS，大数据量时性能崩得无声无息 - SQL Server 2016+：支持
SYSTEM_VERSIONED表上的触发器，但表变量仍不能引用系统时间列（sysstarttime等） - Azure SQL DB：允许在触发器中使用
SEQUENCE，但表变量里不能用NEXT VALUE FOR—— 必须先赋值给普通变量再插入 - 如果你的触发器还调用了 CLR 或链接服务器，表变量无法穿透到远程查询中，会静默转为空集
最稳妥的做法永远是：先用 SET STATISTICS XML ON 看执行计划里表变量的预估行数是否合理；再压测真实数据量级下的响应时间。别信“语法过了就行”。
