MySQL 触发器里不能用 TRY...CATCH
MySQL 原生不支持
TRY...CATCH语法，这是很多从 SQL Server 或 PostgreSQL 转过来的人第一脚踩空的地方。触发器中一旦执行出错（比如插入违反唯一约束、除零、
NULL写入
NOT NULL字段），整个语句会立即中断并回滚，且无法在触发器内部“捕获”并转为警告或默认值。
这意味着：你不能靠触发器兜底业务逻辑错误。常见误操作包括在
BEFORE INSERT里做复杂校验后想“悄悄修正字段”，结果一报错就整个
INSERT失败——不是触发器没运行，而是它运行到一半被 MySQL 强制终止了。
SIGNAL
和 RESIGNAL
是唯一可控的报错方式
MySQL 5.5+ 提供了
SIGNAL语句，允许你在触发器中主动抛出自定义错误，配合
SQLSTATE码和消息，让调用方明确知道问题在哪。它不会被“吞掉”，而是像原生错误一样中断执行、回滚事务。
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '用户名已存在且邮箱未验证';
SQLSTATE '45000'是用户自定义错误的标准码；用
'45001'、
'45002'也能区分不同场景 必须在
BEGIN...END块内使用，且不能放在函数或存储过程调用之后（否则可能被忽略）
RESIGNAL只能在异常处理器（
DECLARE ... HANDLER）中使用，但注意：触发器不支持声明异常处理器——所以
RESIGNAL在触发器里基本无用
替代方案：把校验和修复逻辑移到应用层或存储过程中
真正健壮的错误管理，得绕开触发器本身的能力限制。例如：
需要根据另一张表状态决定是否允许插入？别在BEFORE INSERT里查表后
SIGNAL，而应在应用代码里先
SELECT判断，再决定是否发
INSERT想自动补全缺失字段（如生成
created_at或格式化手机号）？可以用
BEFORE INSERT/UPDATE直接赋值，但前提是字段允许
NULL或有默认值，且逻辑简单无副作用 涉及多表一致性、复杂条件分支、日志记录或重试机制？封装成存储过程，由应用显式调用，而不是塞进触发器
触发器适合做轻量、确定性、无外部依赖的操作，比如更新统计字段、复制时间戳、小写化邮箱。一旦出现
SELECT ... FROM other_table或嵌套
IF判断多个业务规则，它就不再是“辅助工具”，而成了故障放大器。
调试触发器错误时，SHOW ENGINE INNODB STATUS
和错误日志最管用
触发器报错往往不直接显示具体哪行代码崩了，尤其是嵌套调用或与外键冲突交织时。这时候：
执行失败后立刻运行SHOW ENGINE INNODB STATUS\G，查看
LATEST FOREIGN KEY ERROR或
LATEST DETECTED DEADLOCK区块 检查 MySQL 错误日志（路径由
log_error配置项指定），搜索最近的
Error或
ERROR行，常含触发器名和 SQLSTATE 临时把触发器改成只写日志（如插入到一张
debug_log表），确认执行路径是否如预期——但注意：写日志操作本身也可能触发新错误
没有堆栈跟踪，没有行号提示，是 MySQL 触发器调试最让人头疼的一点。写得越“聪明”的触发器，出问题时越难定位。
