sql server触发器需用try/catch静默捕获错误并写入日志表，mysql则只能在before触发器中预检+ signal主动报错；二者均不可捕获运行时异常，日志表写入失败本身也需防范。
触发器里出错就让主操作失败，这不是健壮设计，而是把错误当流程控制。真要记录异常又不中断业务，核心就一条：别让错误往外冒，自己吞掉、记下来、安静结束。
SQL Server 触发器中用 TRY/CATCH 捕获并静默处理
SQL Server 的触发器默认错误会直接中断事务，必须在触发器内部显式包裹 BEGIN TRY/BEGIN CATCH，且不能依赖外层存储过程的 TRY/CATCH。
-
ERROR_NUMBER()、ERROR_MESSAGE()等函数只在 CATCH 块内有效，且ERROR_MESSAGE()最多返回 4000 字符，超长会被截断 - 若不想主事务回滚，CATCH 中不要
THROW或RAISERROR；只写日志表，然后自然退出 - 避免在 CATCH 里调用可能出错的存储过程或复杂逻辑，否则新错误可能被忽略
- 注意语法限制：
BEGIN TRY和BEGIN CATCH必须成对出现在同一作用域，不能跨IF块拆开
示例（AFTER INSERT 触发器，日志失败不阻塞插入）：
CREATE TRIGGER tr_log_on_insert ON dbo.Orders
AFTER INSERT AS
BEGIN
BEGIN TRY
INSERT INTO dbo.AuditLog (order_id, created_at)
SELECT i.id, GETDATE() FROM inserted i;
END TRY
BEGIN CATCH
INSERT INTO dbo.ErrorLog (error_time, error_number, error_message)
VALUES (GETDATE(), ERROR_NUMBER(), ERROR_MESSAGE());
-- 不 THROW，不 RAISERROR → 主 INSERT 继续提交
END CATCH
END
MySQL 触发器无法捕获运行时错误，只能预检 + SIGNAL
MySQL 触发器根本没 TRY/CATCH，任何运行时错误（如唯一键冲突、NULL 插入 NOT NULL 字段）都会直接回滚整个语句，且无法拦截。所谓“记录异常”，只能靠 BEFORE 触发器主动检查 + SIGNAL 控制报错时机。
- BEFORE 触发器中用
IF判断数据合法性，再用SIGNAL SQLSTATE '45000'主动抛出自定义错误——这是唯一可控的“异常记录点” - AFTER 触发器里执行的 DML 若失败，不会进任何 handler，也不会留下痕迹；你看到的只是主语句报错，比如
ERROR 1062 (23000) - 想真正记录错误上下文（谁、何时、哪条数据），必须把逻辑移到存储过程中，用
DECLARE CONTINUE HANDLER FOR 1062捕获冲突并写日志 - 触发器禁止调用含事务或 handler 的存储过程，否则会报
ERROR 1422
示例（BEFORE INSERT 预检邮箱）：
DELIMITER $$
CREATE TRIGGER check_email BEFORE INSERT ON users
FOR EACH ROW
BEGIN
IF NEW.email IS NULL OR NEW.email NOT REGEXP '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$' THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '无效邮箱格式';
END IF;
END$$
DELIMITER ;
日志表设计与写入安全边界
无论哪种数据库，往日志表写记录本身也可能失败（如磁盘满、权限不足、字段长度溢出），这会导致你本想“静默兜底”的逻辑反而引发新错误。必须设防。
- 日志表字段尽量宽松：
error_message用NVARCHAR(MAX)（SQL Server）或TEXT（MySQL），避免截断关键信息 - 避免在日志表上建触发器——尤其是 PostgreSQL，极易因
pg_trigger_depth() > 1导致递归爆栈 - SQL Server 中，如果日志表写入失败且你没包 TRY/CATCH，会直接中断主事务；MySQL 则根本没法在触发器里处理这个失败
- Oracle 需用自治事务（
PRAGMA AUTONOMOUS_TRANSACTION）确保日志写入独立提交，否则主事务回滚会连带清空日志
真正难的不是“怎么记”，而是“记什么”和“记完怎么用”。很多团队花力气写日志表，却从不查 ErrorLog 里的 ERROR_SEVERITY() 错误，或者把 <code>ERROR_LINE() 当成精确位置——其实它指向的是触发器内部语句行号，不是调用它的原始 SQL。这些细节不厘清，日志只会堆成废料。
