SQL Server触发器中TRY…CATCH失效主因是结构破坏：BEGIN TRY与BEGIN CATCH必须连续，不可含GO、跨批或动态SQL；ERROR_*函数仅在CATCH内有效；常见错误包括未ROLLBACK致数据残留、CATCH中未THROW致异常丢失、INSERTED为空引发编译错误。
SQL Server 触发器里 TRY…CATCH 为什么总不生效
不是语法不支持，而是结构被破坏：BEGIN TRY 和 BEGIN CATCH 必须连续出现，中间不能有 GO、不能跨批、也不能藏在动态 SQL 里。ERROR_NUMBER()、ERROR_MESSAGE() 等函数只在 CATCH 块内有效，离开就返回 NULL。
常见错误现象：
-
RAISERROR后没跟ROLLBACK TRANSACTION，数据已写入但错误被“吞掉” - CATCH 块里只调用日志表插入，却没
THROW或RAISERROR，上层应用收不到异常 - 用
SELECT @id = id FROM INSERTED直接取值，但INSERTED为空时触发Invalid column name—— 这类编译期错误根本进不了 CATCH
实操建议：
- 所有业务逻辑必须包裹在
BEGIN TRY ... END TRY内，CATCH中第一句就提取ERROR_NUMBER()、ERROR_MESSAGE()、ERROR_LINE() - 必须用
THROW（SQL Server 2012+）或RAISERROR(..., 16, 1)显式重抛，级别低于 11 的错误不会中断执行流 - 避免在 CATCH 里执行跨库写日志等复杂操作；优先写入内存表（如
@ErrorLogTable），由外部作业统一落盘
MySQL 触发器无法捕获错误，怎么让报错信息可读
MySQL 触发器根本不支持 TRY...CATCH 或 DECLARE HANDLER，出错即回滚，且无机会记录上下文。你看到的“静默失败”，其实是错误直接终止了语句，连日志表都插不进去。
能做的只有主动拦截 + 主动抛出：
- 只在
BEFORE触发器中用SIGNAL SQLSTATE '45000'，AFTER 里 SIGNAL 可能根本没机会执行（先报 ERROR 1442） -
SIGNAL必须搭配SET MESSAGE_TEXT = 'xxx'，否则客户端收到空错误或默认模糊提示 - 别写
SELECT email INTO @tmp FROM users WHERE ...，查不到会触发 ERROR 1329（02000），且无法捕获
实操建议：
- 校验逻辑必须轻量：用索引字段做精确匹配（如
EXISTS (SELECT 1 FROM users WHERE email = NEW.email)），避免全表扫描 - 确保
email字段有索引，否则写入性能直接受损 - 若已有
UNIQUE(email)约束，触发器仅用于替换错误文案——不要重复校验
Oracle 触发器里 RAISE_APPLICATION_ERROR 报错不显示怎么办
报错不显示，大概率是编号或长度越界：RAISE_APPLICATION_ERROR 要求错误号严格落在 -20000 到 -20999 之间，消息字符串不能超 2048 字节，第二参数还不能为空字符串。
常见错误现象：
- 传
-1000或-30000，编译失败，报PLS-00302 - 消息超长，静默截断，不报错也不警告
- 在 SQL 表达式中调用（如
SELECT f() FROM t），直接报ORA-20000
实操建议：
- 固定用
RAISE_APPLICATION_ERROR(-20001, 'xxx')开始编号，避免硬编码魔数 - 拼接错误消息前用
LENGTH()检查长度，超长则截断并加省略号 - 只在 PL/SQL 块里调用，绝不在 SELECT / WHERE 子句中嵌套
所有数据库触发器共通的致命盲区
真正容易被忽略的是：触发器本身**不提供异常捕获机制**。你没法 “try 一下再 fallback”，只能预判条件、提前中断。所谓“容错”，其实是靠前置校验和主动抛出实现的。
这意味着：
- 编译期错误（列名拼错、表不存在）永远进不了任何错误处理块
- 约束冲突（唯一键、外键、非空）属于终止性错误，在 SQL Server 和 MySQL 中都无法被 CATCH 捕获
-
APP_NAME()、HOST_NAME()等上下文函数依赖连接字符串配置，不设就是空，别指望靠它定位真实来源
最稳妥的做法是把重逻辑移出触发器：校验、查重、跨表更新、发邮件——这些都应该放在存储过程或应用层。触发器只保留确定性、无副作用、低开销的操作，比如生成审计字段或简单状态标记。
