MySQL触发器中无法直接SELECT输出，只能通过写日志表或SIGNAL报错实现调试；BEFORE适合校验与修改，AFTER适合审计；错误不记录到error_log，需主动日志或应用层捕获。
MySQL触发器里无法用 SELECT 直接查表并返回结果
触发器运行在语句执行的上下文中，不是独立会话，也不支持交互式输出。你写 SELECT 'debug' 不会打印日志，反而会报错：ERROR 1415 (0S000): Not allowed to return a result set from a trigger。这是最常踩的第一个坑。
真正能记录“日志”的方式只有两种：
- 写入一张专门的日志表（需确保该表是
InnoDB，且触发器有INSERT权限） - 抛出错误中断流程（用
SIGNAL），间接留下线索
CREATE TABLE trigger_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, table_name VARCHAR(64), action VARCHAR(10), old_data JSON, new_data JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
用 SIGNAL 主动报错是唯一可靠的运行时反馈手段
MySQL 触发器不支持 TRY...CATCH，也没有 RAISE 或 THROW（直到 8.0.16 才支持 SIGNAL）。低于这个版本根本没法主动报错，只能静默失败或靠日志表事后排查。
8.0+ 中正确用法：
BEGIN
IF NEW.price < 0 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Price cannot be negative in products table';
END IF;
END
注意点：
-
SQLSTATE必须是 5 位字符串，'45000'是用户自定义错误的标准码 -
MESSAGE_TEXT长度不能超过 128 字符，超长会被截断 -
SIGNAL会立即终止触发器 + 回滚整个原始语句（哪怕是在AFTER触发器里）
BEFORE 和 AFTER 触发器对错误处理的影响完全不同
这是最容易被忽略的语义差异：
-
BEFORE触发器中修改NEW字段是合法的；若此时SIGNAL报错，原始INSERT/UPDATE就不会执行 -
AFTER触发器中不能再改NEW或OLD（会报错ERROR 1362）；但SIGNAL仍会回滚整个事务，包括前面已成功的主语句 - 如果主语句本身失败（如违反外键），
AFTER触发器根本不会运行 —— 日志表也就不会写入
所以关键业务校验逻辑必须放在 BEFORE，而审计类日志写入建议放 AFTER（避免主语句失败导致日志残留脏数据）。
触发器里的错误不会自动记录到 MySQL 错误日志
无论 SIGNAL 还是运行时异常（比如除零、列不存在），默认都只返回给客户端，error_log 文件里不会出现对应条目。这意味着你无法靠翻 mysqld.err 定位触发器问题。
可行的补救方式只有：
- 在触发器内
INSERT INTO trigger_log记录关键字段和GET DIAGNOSTICS获取的部分上下文（MySQL 5.7+） - 开启通用查询日志（
general_log），但性能开销大，仅限临时排障 - 应用层捕获 SQL 错误码（如
1452外键失败、1415触发器返回结果集等），结合业务逻辑做映射
触发器本质是隐式执行的黑盒，越依赖它做核心校验，就越难观测和调试。生产环境建议只用于审计、缓存更新等副作用明确、失败可容忍的场景。
