排查MySQL触发器错误需先检查语法与定义，使用SHOW CREATE TRIGGER确认结构正确；再查看错误日志（log_error路径）定位执行异常；开启通用日志追踪操作行为；手动模拟触发器SQL验证逻辑；检查用户权限与sql_mode影响；通过SIGNAL抛错或写日志表实现调试；最后分析外键约束与锁冲突，结合SHOW ENGINE INNODB STATUS判断死锁问题。
当 MySQL 触发器执行出错时，通常不会直接报错，尤其是在通过应用程序执行语句时，错误可能被掩盖。要排查触发器执行错误，需要结合日志、结构检查和测试手段逐步定位问题。
1. 检查触发器语法与定义
确保触发器本身的 SQL 语法正确，并且引用的表、字段存在。
使用以下命令查看触发器定义：
SHOW CREATE TRIGGER trigger_name;
如果不知道触发器名称，可以先列出所有触发器：
SHOW TRIGGERS;
重点关注：触发时机（BEFORE/AFTER）、触发事件（INSERT/UPDATE/DELETE）、涉及的字段是否存在、是否有拼写错误。
2. 查看错误日志
MySQL 的错误日志是排查问题的第一手资料。触发器在执行过程中若引发异常（如主键冲突、字段超长、数据类型不匹配），通常会在错误日志中记录。
找到 MySQL 配置文件（my.cnf 或 my.ini）中的 log_error 配置项，查看日志路径：
log_error = /var/log/mysql/error.log
执行触发操作后，立即查看该日志文件，搜索关键字如“ERROR”、“trigger”、“deadlock”等。
3. 使用通用日志或慢查询日志辅助分析
开启通用查询日志可记录所有执行的语句，包括触发器内部的操作（但不会直接显示触发器代码执行过程）。
临时开启通用日志：
SET global general_log = ON;
SET global general_log_file = '/tmp/general.log';
执行引发触发器的操作后，查看日志文件，观察是否执行了预期的 INSERT、UPDATE 等动作。
注意：通用日志会影响性能，排查完应关闭。
4. 手动模拟触发器逻辑
将触发器中的 SQL 语句复制出来，在 MySQL 客户端手动执行，传入类似的数据，看是否报错。
例如，一个 BEFORE INSERT 触发器向另一张表插入数据：
INSERT INTO audit_table (user, action) VALUES ('test_user', 'insert');
手动执行这句，看是否提示“Column cannot be null”或“Unknown column”等错误。
这种方法能快速暴露字段约束、外键限制等问题。
5. 检查权限与SQL模式
触发器以定义者的权限运行，需确认触发器定义用户对涉及的表有相应操作权限。
同时，SQL 模式（sql_mode）会影响数据校验行为。例如，在严格模式下，插入 NULL 到 NOT NULL 字段会直接报错，导致触发器失败。
查看当前模式：
SELECT @@sql_mode;
常见问题出现在 sql_mode 包含 STRICT_TRANS_TABLES 时，对非法值更敏感。
6. 利用存储过程调试（间接方式）
MySQL 触发器不支持直接打印或调试，但可通过以下技巧辅助排查：
- 在触发器中插入一条日志记录到专用 debug 表
- 故意制造语法错误（如 SIGNAL）主动抛出异常，确认触发器是否被执行
- 使用 SIGNAL 抛出自定义错误信息：
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Debug: trigger fired but value is null';
这样在执行原操作时就会看到这个明确错误，证明触发器已运行并走到某一步。
7. 检查外键约束与锁冲突
触发器操作的表如果有外键依赖，插入或删除时可能因父表/子表数据不存在而失败。
另外，在高并发场景下，触发器操作可能导致锁等待或死锁，这类问题可在错误日志中发现“Deadlock found”提示。
使用 SHOW ENGINE INNODB STATUS; 查看最近的死锁信息。
基本上就这些方法。关键是把触发器当成一段隐藏执行的 SQL，通过日志、手动验证和错误反馈去还原执行过程。只要一步步排除，大多数问题都能定位。
