MySQL触发器无法捕获运行时异常，错误会直接导致DML回滚且无法用DECLARE HANDLER处理；唯一可行方式是在BEFORE触发器中预检并SIGNAL主动报错。
不能靠错误日志自动捕获触发器异常——它默认静默失败，必须主动埋点或拦截。
为什么SQL Server触发器异常常被漏掉
触发器在事务内执行，一旦出错（比如引用了不存在的列、除零、权限不足），默认行为是直接回滚整个外部语句，并抛出错误——但这个错误不会单独记录到 SQL Server 错误日志，也不会出现在 sys.dm_exec_trigger_stats 的统计里。更麻烦的是，如果触发器里用了 TRY...CATCH 却没 THROW 或 RAISERROR，异常就彻底吞掉了。
常见错误现象：
- 业务侧报告“数据没更新”，但 DML 语句返回成功，
@@ROWCOUNT正常，查不到任何报错 - 触发器中写了
PRINT或RAISERROR(..., 10, 1)（低严重级），客户端根本收不到 - 嵌套触发器中某一层失败，外层语句回滚，但监控只看到主表操作失败，定位不到是哪个触发器炸的
SQL Server：用日志表 + TRYCATCH 捕获异常详情
最可靠的做法是在每个关键触发器里加结构化异常捕获，并写入持久化日志表。不依赖客户端接收消息，也不依赖错误日志留存。
实操建议：
- 先建一张带时间、触发器名、错误号、消息、语句文本的日志表：
CREATE TABLE trigger_error_log (id INT IDENTITY(1,1), trigger_name SYSNAME, error_number INT, error_message NVARCHAR(4000), sql_text NVARCHAR(MAX), log_time DATETIME2 DEFAULT GETDATE()) - 在触发器主体开头加
BEGIN TRY ... END TRY BEGIN CATCH INSERT INTO trigger_error_log (...) VALUES (OBJECT_NAME(@@PROCID), ERROR_NUMBER(), ERROR_MESSAGE(), EVENTDATA().value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]', 'NVARCHAR(MAX)'), GETDATE()); THROW; END CATCH - 注意：
EVENTDATA()只在 DDL 触发器中稳定可用；DML 触发器建议用CONTEXT_INFO()或临时表传入上下文，或直接记录INSERTED/DELETED行数作辅助判断 - 避免在
CATCH块里做复杂逻辑（如调用链接服务器），防止二次失败导致日志丢失
MySQL：靠日志表 + SIGNAL/RESIGNAL 暴露问题
MySQL 触发器不支持 TRY...CATCH，但可以用 SIGNAL 主动抛出错误，并配合日志表实现可观测性。
实操建议：
- 在触发器关键分支后插入日志：
INSERT INTO trigger_debug_log (trigger_name, step, message, created_at) VALUES ('tr_orders_after_insert', 'validate_stock', CONCAT('stock left: ', @remaining), NOW()); - 遇到校验失败时，不要只设变量或跳过，必须
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Stock validation failed in tr_orders_after_insert'; - 若触发器被嵌套调用，且上层已用
DECLARE CONTINUE HANDLER吞了错误，需在 handler 中再次RESIGNAL，否则异常无法透出 - 别依赖
SELECT输出调试信息——MySQL 5.7+ 默认禁用结果集返回，客户端收不到
所有数据库都该防的坑：日志表自身不可用怎么办
触发器里写日志表，最大的风险是日志表本身故障（如被锁、空间满、权限变更）导致整个业务语句失败。这不是理论风险，生产中真实发生过。
关键应对方式：
- 日志表必须和业务表在同一个数据库、同一事务下，但使用
INSERT IGNORE（MySQL）或INSERT ... SELECT ... WHERE EXISTS (SELECT 1 FROM sys.tables WHERE name = 'trigger_error_log')（SQL Server）做存在性兜底 - 对日志写入加超时或轻量级重试（例如 MySQL 用
GET_LOCK('trigger_log_lock', 0)防并发写崩） - 定期清理日志表（比如保留 7 天），并监控其
data_length或行数增长速率，避免磁盘被撑爆 - 最底线：哪怕日志写失败，也绝不能让原始业务逻辑受影响——异常捕获块末尾必须有
RETURN或LEAVE，而不是放任继续执行
真正难的不是记录异常，而是确保记录动作本身不成为单点故障源。日志表不是可选配件，它是触发器的呼吸阀——堵住了，整个系统会窒息。
