sql server的after触发器在语句成功执行后触发，可安全访问inserted和deleted表，用于审计日志；需建日志表并按操作类型（i/u/d）写入变更数据，且必须用集合操作、避免嵌套递归、合理索引以保障性能。
SQL Server 的 AFTER INSERT/UPDATE/DELETE 触发器怎么写
AFTER 触发器在 SQL Server 中是记录变更日志最常用的方式，它在语句成功执行后触发，能安全访问 INSERTED 和 DELETED 临时表。注意：MySQL 和 PostgreSQL 没有原生 AFTER 触发器语法（MySQL 只支持 BEFORE 和 AFTER，但行为与 SQL Server 不同；PostgreSQL 的 AFTER 触发器不支持行级 REFERENCING 表别名），所以这里默认指 SQL Server。
典型写法是为需要审计的表创建一个日志表，再建触发器把变更前/后的值、操作类型、时间、用户等写进去：
CREATE TABLE dbo.Employee_AuditLog (
LogID INT IDENTITY(1,1) PRIMARY KEY,
Operation CHAR(1), -- 'I', 'U', 'D'
EmployeeID INT,
OldName NVARCHAR(100),
NewName NVARCHAR(100),
ModifiedBy SYSNAME DEFAULT SUSER_SNAME(),
ModifiedAt DATETIME2 DEFAULT GETDATE()
);
然后对原表 Employee 建触发器：
CREATE TRIGGER tr_Employee_Audit ON dbo.Employee
AFTER INSERT, UPDATE, DELETE
AS
BEGIN
SET NOCOUNT ON;
IF EXISTS (SELECT * FROM inserted) AND EXISTS (SELECT * FROM deleted)
INSERT INTO dbo.Employee_AuditLog (Operation, EmployeeID, OldName, NewName)
SELECT 'U', i.EmployeeID, d.Name, i.Name
FROM inserted i
INNER JOIN deleted d ON i.EmployeeID = d.EmployeeID;
ELSE IF EXISTS (SELECT * FROM inserted)
INSERT INTO dbo.Employee_AuditLog (Operation, EmployeeID, NewName)
SELECT 'I', EmployeeID, Name FROM inserted;
ELSE IF EXISTS (SELECT * FROM deleted)
INSERT INTO dbo.Employee_AuditLog (Operation, EmployeeID, OldName)
SELECT 'D', EmployeeID, Name FROM deleted;
END;
为什么不能用 INSTEAD OF 替代 AFTER 记录日志
INSTEAD OF 触发器会替代原操作执行，意味着你得手动重写 INSERT/UPDATE/DELETE 逻辑，稍有疏漏就会丢数据或破坏约束。而日志场景的核心诉求是「确保主操作已成功，再追加记录」——这正是 AFTER 的设计目的。
-
AFTER触发器中，事务尚未提交，所以日志写入和主表变更在同一个事务里，要么全成功，要么全回滚 -
INSTEAD OF需要显式执行原操作（比如再写一遍INSERT INTO Employee ...），容易绕过 CHECK 约束、忽略默认值、漏掉计算列更新 - 批量操作（如
UPDATE TOP(1000)）在INSTEAD OF中需额外处理行数控制，AFTER则天然适配
触发器里获取当前用户和主机名的可靠方式
用 SUSER_SNAME() 比 SYSTEM_USER 更稳妥，前者返回登录名，后者可能返回代理账户名；如果应用层传了操作人（如通过 CONTEXT_INFO 或会话变量），优先取那个——因为 SQL Server 默认无法识别应用用户。
常见做法是在应用连接后立即设置上下文：
DECLARE @context VARBINARY(128) = CAST('user:alice@company.com' AS VARBINARY(128));
SET CONTEXT_INFO @context;
然后在触发器里读取：
DECLARE @user NVARCHAR(128) =
CAST(CONTEXT_INFO() AS VARCHAR(128));
SELECT @user = SUBSTRING(@user, 7, LEN(@user)-6)
WHERE @user LIKE 'user:%';
注意：CONTEXT_INFO 是会话级的，且长度上限 128 字节，不适合传长字符串。
触发器日志性能差？这些地方最容易拖慢
日志表没索引、触发器里做远程调用、或在循环中逐行插入，都会让 AFTER 触发器变成性能瓶颈。实际部署时必须检查：
- 日志表的
ModifiedAt字段建议建非聚集索引，尤其当按时间范围查日志频繁时 - 避免在触发器里调用
OPENQUERY、EXEC xp_cmdshell或跨库写入（除非异步队列机制已就位） - 不要用游标遍历
INSERTED/DELETED；所有操作必须基于集合，SQL Server 的触发器天然面向多行 - 如果日志量极大（比如每秒上千条变更），考虑把日志写入内存优化表（
MEMORY_OPTIMIZED），或改用变更数据捕获（CDC）机制
真正难处理的是触发器嵌套和递归——比如日志表自身也有 AFTER 触发器，或者主表触发器又去更新另一张带触发器的表。SQL Server 默认允许最多 32 层嵌套，但一旦开启 RECURSIVE_TRIGGERS，极易陷入死循环，这类逻辑必须人工确认闭环边界。
