mysql触发器无法捕获异常，只能在before阶段通过if预判+ signal sqlstate '45000' set message_text='xxx'主动中断；after中signal无效，且不支持try…catch或declare handler。
MySQL触发器里不能“截获”错误，只能提前预判、主动中断。 所有数据库的触发器都不支持异常捕获机制（比如 DECLARE HANDLER 或 TRY...CATCH），你没法在 INSERT 失败后“捞起来”再改提示——必须在语句执行前，用条件判断堵住问题路径，再用 SIGNAL 扔出定制错误。
为什么 SIGNAL 只能在 BEFORE 触发器里安全使用
因为 AFTER 触发器运行时，原始 INSERT/UPDATE/DELETE 已经完成。如果这时再查表或写表，会直接触发 Can't update table in stored function/trigger 错误，SIGNAL 根本没机会执行。
-
SIGNAL必须放在BEFORE INSERT、BEFORE UPDATE或BEFORE DELETE中，才能真正阻断后续操作 - 哪怕语法上允许在 AFTER 里写
SIGNAL，它也只会在“逻辑上执行”，但客户端收不到——因为前置错误已先报出 - 如果你真需要基于新数据做校验（比如检查更新后的邮箱是否重复），必须在 BEFORE 阶段读
NEW.email，而不是等 AFTER
SIGNAL 的最小合法写法必须带 MESSAGE_TEXT
只写 SIGNAL SQLSTATE '45000' 是无效的：客户端收到的错误信息为空，或显示模糊的默认提示（如 ERROR 1644 (45000)），根本看不出问题在哪。
- 必须显式加上
SET MESSAGE_TEXT = 'xxx'，例如：SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '用户名不能为空' -
SQLSTATE '45000'是通用用户错误码，避免和系统错误（如'23000'外键失败）混淆 - 别用
RESIGNAL——触发器不支持声明错误处理器，无法先捕获再重抛
查重类校验最容易踩的性能坑
用 IF EXISTS (SELECT 1 FROM users WHERE email = NEW.email) 看似简单，但如果 email 字段没索引，每次插入都要全表扫描，写入性能直线下降。
- 确保被查询字段（如
email）有索引，最好是唯一索引；否则这个触发器反而成了瓶颈 - 绝对不要写
SELECT email INTO @tmp FROM users WHERE email = NEW.email——查不到会立刻报ERROR 1329 (02000)，且无法拦截 - 如果表上已有
UNIQUE(email)约束，这个触发器就是冗余的，除非你坚持统一返回中文提示
真正容易被忽略的是：触发器里的校验越重，越该移到应用层。触发器只适合轻量、确定、无副作用的拦截——比如非空、格式、单字段存在性检查。涉及多表关联、远程调用、复杂计算的逻辑，放触发器里既难调试，又容易锁表或拖慢主流程。
