inserted和deleted表是触发器的底层数据载体，非优化工具；批量操作时含多行，硬用WHERE id=@id会漏数据，须用JOIN或EXISTS集合处理。
直接说结论：inserted 和 deleted 表不是“优化工具”，而是触发器的底层数据载体；所谓“优化”，本质是避免误用、减少隐式扫描、防止多行逻辑崩坏。
为什么不能直接 SELECT * FROM inserted WHERE id = @id
因为 inserted 是表，不是标量变量——它可能含 0 行、1 行，也可能是上百行（批量 INSERT/UPDATE）。硬写 WHERE id = @id 并假设单行，会漏掉其他行，且无法处理并发插入。
- 常见错误现象：触发器在单条 INSERT 时正常，批量导入（如
INSERT INTO t SELECT ... FROM s）后只处理了第一条，其余数据静默丢失 - 正确做法：始终按集合思维处理，用
JOIN或EXISTS关联原表或目标表，例如：UPDATE target SET status = 'processed' FROM target INNER JOIN inserted i ON target.id = i.id
- 别试图用
TOP 1+ 变量赋值来“取一行”——这既破坏集合性，又在多行时引入不确定性
UPDATE 触发器里必须同时检查 inserted 和 deleted 吗
不是“必须”，但忽略任一表就等于放弃对变更方向的判断。比如你想只在 price 列被改时才记录日志，仅查 inserted 拿不到旧值，仅查 deleted 拿不到新值。
- 典型场景：审计字段变更，需比对前后值 —— 必须
INNER JOIN inserted i ON ... INNER JOIN deleted d ON ... - 容易踩的坑：写成
IF UPDATE(price) BEGIN ... SELECT price FROM inserted ... END，这只能说明列参与了 UPDATE，但无法确认值是否真变了（比如 SET price = price） - 性能影响：JOIN 本身开销小，但若在
inserted上建非必要索引（比如手动 CREATE INDEX）会失败——这两个表不支持 DDL，任何索引尝试都会报错Invalid object name 'inserted'
如何安全地在触发器中调用跨库或跨服务器操作
不能直接在 inserted 上做四部分命名查询（如 SELECT * FROM otherdb.dbo.t JOIN inserted i ...），SQL Server 不允许在触发器中对 inserted 或 deleted 做远程 JOIN。
- 正确路径：先将关键字段（如主键、时间戳）从
inserted提取到本地临时表，再用该临时表驱动远程操作SELECT id, RecTime INTO #tmp FROM inserted; INSERT INTO otherdb.dbo.audit_log SELECT id, RecTime, GETDATE() FROM #tmp;
- 为什么必须中转：远程查询会引发分布式事务，而触发器上下文默认不允许
SET XACT_ABORT ON外的显式事务控制，极易卡死或超时 - 兼容性注意：SQL Server 2019+ 支持
INSERTED在某些链接服务器场景下有限使用，但行为不稳定，生产环境一律走临时表中转
最常被忽略的一点：inserted 和 deleted 表内容不可修改，也不可加索引，更不能在触发器外访问——它们的生命期严格绑定于触发器执行栈。一旦你在触发器里做了耗时操作（比如发 HTTP 请求、写文件），这些表早已销毁，后续任何依赖它们的逻辑都会报 Invalid object name。
