因为触发器中SIGNAL只能在BEFORE类型中中断原操作，AFTER触发器无法阻止已执行的INSERT；且需确保SIGNAL写在拦截分支、消息安全、避免NULL拼接、不修改触发表，并注意事务回滚与版本兼容性。
触发器里用 SIGNAL SQLSTATE 抛异常，为什么没拦住 INSERT？
因为 MySQL 触发器中 SIGNAL 只在执行到它时中断当前语句，但前提是：触发器本身必须是 BEFORE 类型，且不能在 AFTER 触发器里用——AFTER 触发器无法阻止原操作，它运行时数据已经改完了。
-
BEFORE INSERT/BEFORE UPDATE/BEFORE DELETE才能真正拦截 -
SIGNAL SQLSTATE '45000'是最低开销的通用错误码，别用'HY000'或其他保留态，MySQL 会忽略或报错 - 如果触发器里有多个条件判断，
SIGNAL必须写在实际要拦截的分支里，别漏掉ELSE或默认路径
SIGNAL 的消息内容会被客户端看到，怎么写才安全？
消息字符串会直接透出给应用层，比如 Python 的 mysql.connector.Error 异常里含 msg 字段。别写敏感信息、SQL 片段或调试路径，只描述业务约束，比如“年龄不能小于 0”而不是“CHECK age >= 0 failed at line 12”。
- 用单引号包裹字符串：
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '用户状态不可设为已删除'; - MySQL 5.7+ 支持
MESSAGE_TEXT最长 128 字符；超长会被截断，不报错也不警告 - 避免动态拼接（如
CONCAT('ID ', NEW.id, ' 无效')），除非你确认NEW.id绝对非 NULL —— NULL 会让整条SIGNAL失效（静默跳过）
和外键、CHECK 约束比，SIGNAL 在触发器里更适合什么场景？
外键管关联，CHECK 管单列静态规则，而 SIGNAL 在触发器里能做跨表校验、逻辑组合判断、甚至调用函数——比如“同一用户当天最多下 3 单”，这种需要查另一张表计数的，只能靠触发器 + SIGNAL。
- 注意性能：触发器里查表会锁行，高并发下容易成瓶颈；尽量用
SELECT ... FOR UPDATE显式加锁，别依赖隐式行为 - MySQL 8.0.16+ 的
CHECK支持子查询了，但多数旧版本不支持，所以触发器仍是主力 - 别在触发器里改触发它的表（比如
BEFORE INSERT里又UPDATE同一表），会报ERROR 1442 (HY000): Can't update table ... in stored function/trigger
测试 SIGNAL 是否生效，最容易被忽略的点是什么？
本地用 mysql 命令行测试时，默认开启自动提交（autocommit=1），看起来 SIGNAL 生效了；但应用里如果开了事务，而你没检查事务是否回滚，可能误以为拦截失败——其实异常抛出了，只是上层没处理，事务还挂着。
- 用
SHOW ENGINE INNODB STATUS\G查最近死锁或锁等待，确认触发器是否真卡在查表环节 - 在应用端捕获异常后，显式执行
ROLLBACK；别依赖框架自动回滚，有些 ORM（如老版 Django）对触发器异常不敏感 - 用
SELECT @@autocommit;和SELECT @@sql_mode;核对环境，某些sql_mode（如STRICT_TRANS_TABLES）会影响SIGNAL行为
触发器里的 SIGNAL 不是银弹，它绕不开事务隔离级别、锁粒度和 MySQL 版本差异。上线前一定在真实并发路径下压测，而不是只跑单条 SQL。
