SQL Server中直接INSERT日志会被主事务回滚，因其共享会话级事务上下文；需用TRY...CATCH配合XACT_STATE()判断状态（仅=0时安全写入），或通过Service Broker异步解耦，同时优化日志表结构避免性能瓶颈。
为什么直接 INSERT 日志会被主事务回滚掉
SQL Server 的事务是会话级的，所有语句共享同一个事务上下文。哪怕你在存储过程里写 INSERT INTO LogTable，只要外层调用者开了事务且最终执行了 ROLLBACK，这条日志也会跟着一起消失——不是没执行，是执行了但被回滚了。
- 常见错误现象：业务失败后查不到任何日志，误以为日志代码没跑
- 根本原因：日志表操作和业务逻辑在同一个事务链路里，无法解耦
- 性能影响：加
SAVE TRAN或嵌套BEGIN TRAN都无效，SQL Server 不支持“真正独立提交”的子事务
用 TRY...CATCH + XACT_STATE() 判断事务状态再写日志
这是最轻量、兼容性最好（SQL Server 2005+）的方案：不依赖外部服务，也不改架构，只靠逻辑控制。
- 在
CATCH块里先用XACT_STATE()检查当前事务状态：-1表示不可提交（已异常），0表示无活动事务，1表示可提交 - 只有
XACT_STATE() = 0时才安全插入日志——说明主事务已经退出或未开启，此时日志写入不会被回滚 - 如果状态是
-1，不能直接INSERT，否则会报错 “The current transaction cannot be committed and cannot support operations that write to the log file”
示例片段：
BEGIN TRY
-- 业务逻辑，比如 UPDATE 用户余额
UPDATE Accounts SET Balance = Balance - @amount WHERE Id = @userId;
END TRY
BEGIN CATCH
IF XACT_STATE() = 0
BEGIN
INSERT INTO ErrorLog (ProcName, ErrorMessage, ErrorTime)
VALUES (OBJECT_NAME(@@PROCID), ERROR_MESSAGE(), GETDATE());
END
-- 其他处理：RAISERROR / RETURN 等
END CATCH用触发器或 Service Broker 实现真正异步日志（适合高可靠性场景）
当必须保证“哪怕主事务崩溃，日志也得留下”，就得跳出事务上下文。触发器和 Service Broker 是仅有的两个原生可控手段。
-
AFTER INSERT触发器本身在事务内，不行；但INSTEAD OF+ 显式COMMIT也不推荐，会破坏主逻辑一致性 - Service Broker 可以把日志消息发到队列，由激活的存储过程异步消费并插入——它天然脱离调用者的事务
- 缺点：配置复杂，需要启用
ENABLE_BROKER，且 SQL Server Express 不支持 - 更现实的折中：用
sp_executesql调用另一个数据库（如LogDB）里的存储过程，前提是日志库和业务库分离
最容易被忽略的细节：日志表结构与索引设计
日志写入高频、几乎只增不查，但很多人按业务表习惯建主键+聚集索引，结果导致插入性能断崖下跌。
- 避免在
datetime字段上建聚集索引——新数据总插在末尾，页分裂严重 - 推荐用
IDENTITY主键 + 非聚集索引，或者干脆用堆表（CREATE TABLE不带主键） - 日志字段别加太多约束：
CHECK、DEFAULT GETDATE()可以留，但FOREIGN KEY会拖慢插入，且毫无必要 - 如果日志量极大（比如每秒上千条），考虑分区表按月切分，否则单表膨胀后
DELETE清理会锁死整个表
真正卡住人的往往不是怎么记日志，而是日志表自己成了性能瓶颈，或者某天发现磁盘被 ErrorLog 吃光了却没法快速删——这些都得在建表那一刻就想清楚。
