inserted 不是临时表，而是触发器中只读的内存快照虚拟行集，无物理存储，不支持建索引；真正可建索引的是 # 和 ## 临时表。

INSERTED 临时表不能建索引——它根本不是真正的“表”，而是 DML 触发器中一个只读的逻辑结果集视图，底层没有物理存储结构，自然不支持 CREATE INDEX。

INSERTED 不是临时表，是触发器上下文中的虚拟行集

很多人误以为 INSERTED 是类似 #temp 的临时表，但实际它只是 SQL Server 在 AFTER 或 INSTEAD OF 触发器执行期间，为刚插入/更新/删除的数据提供的**内存中快照引用**。它没有对象 ID、不占 tempdb 空间、不能被 SELECT INTO、也不能 ALTER 或 DROP。

• INSERTED 和 DELETED 只在触发器作用域内存在，离开触发器体就不可访问
• 尝试执行 CREATE INDEX IX ON INSERTED(col) 会直接报错：Msg 102, Level 15, State 1, Line X: Incorrect syntax near 'INSERTED'.
• 它不支持 TRUNCATE、UPDATE、INSERT（除作为 FROM 源外），甚至不能加表别名后用 AS（语法限制）

真正能建索引的“临时表”只有 # 和 ## 开头的那些

只有显式用 CREATE TABLE #t 或 SELECT ... INTO #t 创建的局部/全局临时表，才分配 tempdb 中的页和 IAM 结构，才能走完整 DDL 流程。这类表支持：

• CREATE CLUSTERED INDEX（含主键隐式创建）
• CREATE NONCLUSTERED INDEX（带 INCLUDE 或 WHERE 过滤）
• 索引可建在 tempdb 的任意文件组上（包括 PRIMARY 或自定义）
• SQL Server 2014+ 还支持在临时表上建内存优化索引（若启用内存优化）

想加速触发器里对 INSERTED 的处理？换思路

既然不能索引 INSERTED，就得绕开它做预处理：

• 把 INSERTED 数据先 INSERT INTO #staging —— 这个 staging 表可以提前建好索引
• 避免在触发器里对 INSERTED 做多表 JOIN 或子查询；改用 CTE + ROW_NUMBER() 控制数据流
• 如果业务允许，用 INSTEAD OF 触发器接管插入逻辑，自己控制中间表生命周期
• 高频小批量场景下，考虑用表变量 @t 替代（但注意：表变量不支持显式索引，仅靠主键/唯一约束生成隐式索引）

容易被忽略的关键点

最常踩的坑不是“怎么建索引”，而是没意识到 INSERTED 的生命周期和语义边界：

• 触发器嵌套时，每个层级的 INSERTED 是独立快照，不会叠加
• 批量插入（如 BULK INSERT）触发的触发器，INSERTED 可能包含数千行，但查询计划仍按“小结果集”估算，易导致参数嗅探失效
• 在 INSTEAD OF 触发器中，INSERTED 是唯一数据源，必须用它驱动后续逻辑——这时 staging 表 + 预建索引就是刚需