MySQL 5.7 支持在 BEFORE 触发器中用 SIGNAL 抛出自定义 SQLSTATE 错误码（如 '45000'）并设置 MESSAGE_TEXT，但不支持在 AFTER 触发器中使用——因执行时机已无法拦截操作；SQLSTATE 必须为合法 5 位字符串，超长消息会被静默截断，且触发器中不支持 DECLARE HANDLER。
MySQL 5.7 触发器不能自定义 SQLSTATE 错误码？其实是支持的，但有硬限制
MySQL 5.7 支持在 BEFORE 触发器中用 SIGNAL 抛出自定义错误，包括指定 SQLSTATE 和 MESSAGE_TEXT；但它**不支持在 AFTER 触发器里用 SIGNAL 拦截已发生的修改**——不是“不支持错误码”，而是执行时机决定了你根本没机会干预。
常见误解是看到报错 ERROR 1415 (0A000): Not allowed to return a result set from a trigger 就以为“触发器不能报错”，其实那是另一类问题（SELECT 返回结果集），和 SIGNAL 完全无关。
-
SIGNAL只能在BEFORE触发器中安全使用；AFTER中调用会直接报ERROR 1362 (HY000): Updating of NEW row is not allowed in after trigger -
SQLSTATE必须是 5 位字符串，如'45000'（用户自定义类）、'22003'（数值越界）；用'ERR01'这种非法格式会报语法错误 -
MESSAGE_TEXT超过 128 字符会被静默截断，且不会报错——容易导致客户端收到不完整提示 - 一旦
SIGNAL执行，整个原始语句（比如INSERT）立刻回滚，无法捕获或降级处理
为什么 DECLARE HANDLER 在触发器里完全无效？
MySQL 5.7 的触发器上下文**不支持异常处理器声明**。哪怕你写 DECLARE EXIT HANDLER FOR SQLEXCEPTION，也会被忽略——这不是遗漏，是引擎层明确禁用。
典型失败场景：想在触发器里查配置表做开关控制，但配置缺失时不想让主语句失败，而是跳过逻辑。这时 SELECT ... INTO @var 遇到 0 行就会崩出 ERROR 1329，且无法拦截。
- 所有带
INTO的查询必须确保返回恰好一行；用(SELECT col FROM config WHERE key = 'flag' LIMIT 1)也不行——LIMIT不改变多行可能性，仍可能报ERROR 1242 - 替代方案只有两种：提前用
EXISTS判断再查，或把查询逻辑移到应用层/存储过程中 - 试图在触发器里写日志表记录错误？如果日志表本身写入失败（如磁盘满、权限不足），整个触发器就挂，主语句也跟着回滚
ERROR 1442 和 SIGNAL 看似无关，实则共享同一底层约束
触发器里禁止更新自身表（ERROR 1442）和禁止在 AFTER 中用 SIGNAL，根源都是 MySQL 对“语句原子性”的强保证：它不允许在一条 DML 的执行链中，出现任何可能中断或重入的分支点。
换句话说，SIGNAL 在 AFTER 里被禁，不是因为实现难度，而是设计上拒绝“已提交数据还能被回滚”这种语义。而 ERROR 1442 是防止表锁重入，两者都卡在同一个内核检查环节。
- 如果你在
BEFORE UPDATE里SET NEW.status = 'pending'，再SIGNAL校验失败，原始UPDATE就不会发生 - 但如果你在
AFTER UPDATE里先写了日志，再SIGNAL，MySQL 会直接拒绝创建这个触发器——语法校验阶段就报错，不让你存进数据库 - 真正需要“失败后补救”的逻辑（比如主表失败，仍要发通知），别塞进触发器；用存储过程封装主语句 + 异常处理块更可控
调试时看不到错误日志？这是默认行为，不是 bug
无论 SIGNAL、ERROR 1442 还是 SELECT INTO 崩溃，MySQL 5.7 **都不会把错误写进 error_log 文件**。客户端收到报错，服务端日志里空空如也。
这意味着靠看 /var/log/mysql/error.log 排查触发器失败，基本是徒劳。你得换路径：
- 在触发器开头加
INSERT INTO debug_log VALUES (NOW(), 't_before_update_start', NEW.id);，靠日志表时间戳定位卡点 - 用
SELECT VERSION()确认真是 5.7.x，而不是误连到 5.6 实例（后者连FOLLOWS都不认） - 检查触发器名是否和已有函数/过程重名——
ERROR 1304 (42000): PROCEDURE xxx already exists会伪装成语法错误
最易被忽略的一点：所有这些限制都不是临时配置能绕开的。它们是 InnoDB 和 SQL 解析器在编译期就硬编码的规则，升级到 8.0 也不会解除——只是增加了更多诊断能力，比如 INFORMATION_SCHEMA.TRIGGERS 多了执行顺序字段。
