sql server触发器可用try…catch捕获错误并写入日志，需在catch中立即保存error_*()函数值、避免嵌套异常；postgresql用exception块捕获更直接，但需注意dml默认提交；mysql触发器无法捕获存储引擎级错误，仅支持主动signal。
SQL Server 里触发器怎么用 TRY…CATCH 捕获错误
SQL Server 触发器本身不支持直接抛出可被上层捕获的异常（比如 RAISERROR 不会中断事务链），但可以用 TRY…CATCH 块包裹核心逻辑，把错误信息提取出来写入日志表。关键点是：必须在 CATCH 块里调用 ERROR_*() 系列函数获取上下文，且不能在 CATCH 中再引发未处理异常——否则可能触发嵌套回滚或事务状态异常。
常见错误现象：直接在触发器里写 RAISERROR 后没加 RETURN，导致后续逻辑继续执行；或者在 CATCH 里调用 INSERT 到日志表时又出错，整个事务失败。
-
ERROR_NUMBER()、ERROR_MESSAGE()、ERROR_LINE()必须在CATCH块第一行就存进变量，后续语句可能覆盖这些值 - 日志表插入操作要尽量轻量，避免引用复杂视图或触发其他触发器
- 不要在
CATCH中调用THROW（除非明确想让上层也收到错误），否则可能打断业务逻辑的异常处理流程
PostgreSQL 触发器如何用 EXCEPTION 捕获并写日志
PostgreSQL 的 PL/pgSQL 触发器用 EXCEPTION 块捕获错误更直接，但要注意：默认情况下，触发器内未捕获的异常会导致整个 DML 语句回滚，而捕获后若不重新抛出，DML 仍会成功提交——这容易让人误以为“错误被吞掉了”。
使用场景：你想记录约束冲突（比如唯一键重复）、计算字段越界、或外部函数调用失败，但又不想让业务 SQL 失败。
- 在
EXCEPTION块里用GET STACKED DIAGNOSTICS提取pg_exception_context和pg_exception_detail，比只靠SQLERRM更准 - 日志表字段建议包含：
trigger_name、table_name、operation（'INSERT'/'UPDATE'/'DELETE'）、error_time、error_code、error_message - 避免在
EXCEPTION块里做耗时操作（如调用外部 HTTP 接口），否则拖慢主事务
MySQL 触发器没法直接捕获运行时错误？
MySQL 5.7+ 的触发器不支持 DECLARE HANDLER 捕获所有错误（比如违反外键、数据截断），它只能捕获明确用 SIGNAL 抛出的自定义错误。也就是说，你无法像 SQL Server 或 PostgreSQL 那样拦截一条 INSERT 因主键冲突而失败的过程。
实际能做的：在触发器逻辑开头做防御性检查（例如查重、长度校验），提前用 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'xxx' 主动报错，并在 DECLARE CONTINUE HANDLER FOR SQLEXCEPTION 里记录日志——但这仅适用于你主动控制的分支，不是真正的“异常捕获”。
- 真正由存储引擎抛出的错误（如
ERROR 1062 (23000): Duplicate entry）无法被触发器内的HANDLER捕获 - 如果一定要记录这类错误，得靠应用层或 MySQL 错误日志 + 解析，触发器层面无解
-
HANDLER只对当前触发器作用域生效，不能跨触发器传递状态
日志表设计和写入时机的坑
很多人建个 error_log 表就往里插，结果发现某些错误根本没记上——问题常出在事务隔离和写入时机上。
性能影响明显：如果日志表有索引、触发器、或跟主表在同一个文件组，高并发下写日志会拖慢主业务。
- 日志表务必用
ENGINE=InnoDB（MySQL）或WITH (DELAYED_DURABILITY = ON)（SQL Server），降低写入延迟 - 避免在触发器里用
SELECT … INTO或子查询填充日志字段，容易引发死锁 - PostgreSQL 中，若日志表也定义了触发器，确保它不会递归调用自身（比如用
IF NOT pg_trigger_depth() > 1 THEN过滤）
最易被忽略的是：不同数据库对“触发器中事务状态”的处理差异极大。SQL Server 的 CATCH 后事务可能处于不可提交状态，PostgreSQL 的 EXCEPTION 后事务仍活跃，MySQL 则压根没提供可靠的错误上下文。别指望一套代码到处跑。
