XACT_STATE() 在 SQL Server 触发器中可有效判断事务状态：返回 1 表示可提交，-1 表示已损坏（常因分布式事务失败），0 表示无活动事务；它不直接区分本地或分布式事务，但 -1 是 DTC 干预的强信号，且触发器内调用安全可靠。
SQL Server 中用 XACT_STATE() 判断事务状态是否有效
在触发器里直接判断“是不是分布式事务”没有原生函数，但可以间接推断：XACT_STATE() 返回值能告诉你当前事务是否可提交、是否已损坏。返回 1 表示事务活跃且可提交，-1 表示已不可提交（常因分布式事务失败或 ROLLBACK 被触发），0 表示无活动事务。注意：它不区分本地事务和分布式事务，但 XACT_STATE() = -1 通常意味着事务已被 DTC（MSDTC）介入并中止——这是分布式事务出问题的强信号。
-
XACT_STATE()必须在事务上下文中调用，否则始终返回0；触发器天然处于事务中，所以安全 - 不要用
@@TRANCOUNT替代——它只计嵌套层数，无法反映事务健康状态 - 如果触发器内执行了
SAVE TRANSACTION，XACT_STATE()仍能正确反映最外层事务状态
通过 sys.dm_exec_sessions 查 transaction_isolation_level 辅助判断
分布式事务（如跨数据库或跨服务器的 SELECT + UPDATE）常伴随特定隔离级别变化。虽然不能 100% 确认是分布式事务，但若会话的 transaction_isolation_level 为 0（未指定）、4（可重复读）或 5（快照），再结合 XACT_STATE() = 1，就值得警惕——尤其当该会话正参与 sp_getbindtoken 或 sp_bindsession 流程时。
- 查询需 JOIN
sys.dm_exec_requests获取当前请求的session_id - 仅限 SQL Server，且要求 VIEW SERVER STATE 权限；生产环境触发器中慎用，避免权限或性能问题
- 该方法本质是旁证，不能替代事务状态检查，但可辅助日志标记“疑似分布式上下文”
触发器中避免对分布式事务做 COMMIT 或 ROLLBACK
触发器永远不能发起事务控制语句。一旦检测到 XACT_STATE() = -1，唯一安全做法是让上层应用决定如何处理——你只能记录日志、抛出自定义错误（如 RAISERROR('Distributed transaction aborted', 16, 1)），或设置输出参数通知调用方。强行 ROLLBACK TRAN 在触发器里会报错 Msg 3609, Level 16：“The transaction ended in the trigger. The batch has been aborted.”
- 所有事务控制必须由显式开启事务的应用层或存储过程完成
- 即使用了
TRY...CATCH，CATCH块中也不能COMMIT—— 只能THROW或RAISERROR - 若需清理资源（如临时表），用
DROP TABLE IF EXISTS #tmp这类语句，它们不依赖事务状态
MySQL / PostgreSQL 触发器不支持事务状态检测
MySQL 的触发器运行在语句级事务中，无等价于 XACT_STATE() 的系统函数；@@in_transaction 只能告诉你是否在事务里，无法区分本地/分布式。PostgreSQL 更严格：触发器函数不允许执行事务控制命令，且无内置视图暴露事务协调器信息。这两者本质上不支持“判断分布式事务”，因为其分布式事务能力本身受限（MySQL 需 XA 且客户端主动管理，PostgreSQL 依赖外部协调器如 pgpool，且触发器无访问权限）。
- MySQL 若启用
XA START，触发器内调用XA RECOVER会报错，不可行 - PostgreSQL 中试图在触发器里查
pg_prepared_xacts需超级用户权限，且结果不反映当前会话状态 - 跨库操作在 MySQL/PG 中通常靠应用层拆分事务，触发器不该承担状态决策职责
XACT_STATE() 得配合错误传播机制——比如把 XACT_STATE() = -1 转为带明确错误号的 THROW，否则上层应用可能静默失败。 
