inserted和deleted是sql server触发器内自动创建的内存逻辑表，仅限触发器内使用，必须显式指定字段名、用主键inner join对齐，null比较需用isnull/coalesce，禁用system_user而应通过context_info传操作人，after触发器不可读text/ntext/image列。
Inserted和Deleted表只能在触发器体内直接SELECT或JOIN
这两张表是SQL Server自动创建的内存逻辑表，不是物理表，也不支持CREATE/ALTER/DROP。你不能在触发器外查它们，也不能用SELECT *偷懒——必须显式写出字段名，否则在UPDATE场景下容易漏掉主键或时间戳，导致日志无法关联原记录。
常见错误是写成SELECT * FROM Inserted后直接INSERT进日志表，结果字段顺序错位、NULL值处理失效，甚至因列数不匹配报错Column name or number of supplied values does not match table definition。
- INSERT触发器中，只读
Inserted，Deleted为空（但引用它不报错） - DELETE触发器中，只读
Deleted，Inserted为空 - UPDATE触发器中，两张表都非空，且行数严格相等，必须靠主键JOIN对齐
UPDATE触发器里怎么安全比对新旧值？
别用IF d.col != i.col这种写法——遇到NULL时整个条件返回UNKNOWN，整行被跳过。正确做法是用ISNULL(d.col, '') != ISNULL(i.col, '')或COALESCE(d.col, '') != COALESCE(i.col, '')。
更关键的是JOIN方式：必须用主键（或唯一约束列）做INNER JOIN，不能靠顺序或ROW_NUMBER()强行对齐。没有主键的表，Inserted和Deleted的行序不保证一致，按顺序匹配在并发或批量更新下必然出错。
- 单列主键：写
FROM Deleted d INNER JOIN Inserted i ON d.id = i.id - 复合主键：比如
(order_id, line_no)，就得写全ON d.order_id = i.order_id AND d.line_no = i.line_no - 避免
LEFT JOIN——除非你在INSTEAD OF触发器里要区分操作类型
为什么不能用SYSTEM_USER记录操作人？
在触发器里调用SYSTEM_USER拿到的是SQL登录名（比如sa），不是应用层用户；ORIGINAL_LOGIN()虽能取最初连接名，但在Web应用+连接池场景下，实际看到的常是中间件账号（如IIS APPPOOL\DefaultAppPool）。
真实业务中，操作人信息必须由应用层通过CONTEXT_INFO传入，再在触发器里用CONVERT(VARCHAR(128), CONTEXT_INFO())取出。这是唯一可靠方式。
- 别在触发器里写
INSERT INTO LogTable ... VALUES (SYSTEM_USER, GETDATE(), ...) - 应用代码需在事务开始前执行
SET CONTEXT_INFO 0x...;（二进制格式） - 触发器中记得判空：
CONVERT(VARCHAR(128), CONTEXT_INFO())可能为NULL
AFTER触发器里访问text/ntext/image列会报错
SQL Server明确禁止在AFTER触发器中读取Inserted或Deleted里的text、ntext、image列，会直接抛出错误Cannot reference the text, ntext, and image data types in the inserted and deleted tables。
如果你真需要这类大字段的变更日志，唯一办法是改用INSTEAD OF UPDATE触发器——它允许访问这些类型，但代价是你得自己实现UPDATE逻辑（先删旧、再插新），复杂度陡增。
- 现代方案建议：把
text/ntext升级为varchar(max)/nvarchar(max)，它们在AFTER触发器中可正常读取 - 如果无法改类型，且必须审计大字段，就只能接受INSTEAD OF带来的额外维护成本
真正难的不是语法，而是当一次UPDATE影响上万行时，SELECT d.id, d.content, i.content FROM Deleted d INNER JOIN Inserted i ON d.id = i.id这种写法会把所有宽列全拉出来，瞬间吃光内存。字段越少、JOIN越精准，触发器才越扛得住压。
