mysql触发器失败需查错误日志，确认log_error路径并启用log_warnings=2； strict_trans_tables模式下才报错，否则静默；用declare handler捕获异常并signal抛错；注意handler类型必须为continue；load data infile等操作可能跳过触发器。
触发器执行失败时如何查看错误日志
MySQL 触发器失败默认不抛出明显错误，尤其在 INSERT / UPDATE 语句中静默失败，最直接的方式是查错误日志。需确认 log_error 配置指向的文件路径，并检查是否启用了 log_warnings = 2（MySQL 5.7+ 默认开启，可记录更详细的 SQL 错误上下文）。
常见遗漏点：
-
sql_mode中含STRICT_TRANS_TABLES才会中止执行并报错；否则可能转为警告或截断数据，触发器逻辑实际未生效 - 触发器内调用的存储函数若含
SELECT ... INTO但无匹配行，会触发NO_DATA_FOUND异常，但若未用DECLARE HANDLER捕获，整个触发器就中断 - 跨库操作（如
INSERT INTO other_db.table）失败时，错误可能只记在日志里，客户端看不到
如何在触发器内主动捕获和报告异常
MySQL 触发器不支持 TRY...CATCH，但可用 DECLARE ... HANDLER 捕获特定 SQLSTATE 或 MySQL 错误码，并配合 SIGNAL 主动抛出自定义错误，强制中断并返回明确信息。
示例：防止空值写入关键字段时静默忽略
DELIMITER $$
CREATE TRIGGER check_name_before_insert
BEFORE INSERT ON users
FOR EACH ROW
BEGIN
DECLARE CONTINUE HANDLER FOR SQLSTATE 'HY000'
BEGIN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Trigger failed: user name cannot be empty';
END;
IF NEW.name IS NULL OR TRIM(NEW.name) = '' THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid name value';
END IF;
END$$
DELIMITER ;
注意：HANDLER 类型必须是 CONTINUE（不能用 EXIT），否则触发器退出后主语句仍可能继续执行，造成数据不一致。
触发器调试常用绕过手段
线上环境无法直接加 SELECT 输出调试信息，但可通过副作用方式验证执行路径：
- 往一个专用日志表
trigger_debug插入记录，包含NOW()、USER()、NEW.id等上下文 - 用
SELECT ... INTO @var赋值，再通过客户端查SELECT @var确认是否走到某分支（仅限当前会话） - 临时把触发器改成
BEFORE+SET NEW.col = ...并故意设成非法值，观察是否报错，从而反推是否被触发
慎用：不要在生产触发器里留 INSERT INTO debug_log，高并发下易成性能瓶颈；也不要用 SELECT SLEEP(1) 类调试，会阻塞事务。
哪些操作会导致触发器完全不触发
这是最容易误判的“失败”——其实根本没运行。常见原因包括：
-
LOAD DATA INFILE默认跳过触发器（除非显式加SET FOREIGN_KEY_CHECKS=1且版本 ≥ 5.7.12） - 使用
INSERT IGNORE或REPLACE INTO时，若唯一键冲突导致行被忽略/替换，对应触发器仍会执行；但INSERT ... ON DUPLICATE KEY UPDATE的UPDATE分支不会触发UPDATE触发器（只有真正执行 UPDATE 语句才会） - 从库上
replicate_do_table等复制过滤规则可能让 DML 不应用，自然触发器也不跑 - 触发器定义在分区表上，但操作的数据落在未定义触发器的分区（MySQL 不支持按分区单独设触发器）
最稳妥的验证方式：在测试库用最小化语句复现，同时打开 general_log 查看完整执行链路，确认触发器名是否出现在日志中。
