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触发器返回结果集等），结合业务逻辑做映射
触发器本质是隐式执行的黑盒，越依赖它做核心校验，就越难观测和调试。生产环境建议只用于审计、缓存更新等副作用明确、失败可容忍的场景。
