触发器报错无提示时，应立即执行show warnings查看真实错误；若为空则查错误日志（需log_warnings=2），并确认触发器status为enabled、definer权限正确且sql_log_bin=1。
触发器报错但没提示，先看 SHOW WARNINGS
MySQL 触发器执行失败时，客户端常收不到明确错误，只看到主语句失败或静默跳过。真正有用的线索往往藏在 SHOW WARNINGS 里——它会立刻吐出触发器内部的真实报错，比如 Unknown column 'price' in 'NEW' 或 Column 'status' cannot be null。
- 必须在引发触发器的 INSERT/UPDATE/DELETE 语句执行后**立刻**执行
SHOW WARNINGS;，延迟执行可能被后续语句覆盖 - 如果返回空结果，不代表没问题，而是错误被事务回滚吞掉了，得转向错误日志
- 该命令不依赖权限，任何有查询权限的用户都能用，适合开发和运维快速初筛
错误日志里搜 ERROR 和表名，别只盯触发器名
MySQL 错误日志（路径由 log_error 变量指定）是最终证据源。触发器里违反约束、类型不匹配、锁冲突等，都会落盘记录，但关键词往往不是 trigger，而是具体失败动作。
- 打开日志文件后，优先搜索
ERROR+ 你操作的表名（如orders），再搜deadlock、duplicate、NULL等常见失败模式 -
log_warnings = 2必须开启（SET GLOBAL log_warnings = 2;），否则部分警告不会写入错误日志 - 注意时间戳：触发器执行日志通常紧挨着主 DML 语句的日志行，前后 1 秒内是重点排查窗口
触发器根本没运行？查 information_schema.TRIGGERS 的 STATUS
“触发器写了但没反应”，八成是它被禁用了。MySQL 和 SQL Server 都不报错、不提醒，只安静挂在那里。
- 运行
SELECT TRIGGER_NAME, STATUS FROM information_schema.TRIGGERS WHERE TRIGGER_NAME = 'your_trigger_name';，确认STATUS是ENABLED - 若为
DISABLED，MySQL 5.7 无法直接启用，只能DROP TRIGGER后重建；8.0+ 可用ALTER TRIGGER ... ENABLE -
SHOW TRIGGERS输出不可靠——它只查当前数据库，跨库触发器必须先USE db_name再查
程序里报错但 Navicat 里正常？重点核对 DEFINER 和 host
DBA 工具能跑通，程序一连就崩，本质是权限上下文不一致。程序连接用户（如 'app_user'@'10.0.2.%'）和触发器定义者（如 'root'@'localhost'）权限不同，MySQL 按 DEFINER 权限校验，而非调用者。
- 用
SHOW CREATE TRIGGER your_trigger_name;查DEFINER字段，确保该用户存在且对触发器内所有表有对应 DML 权限 - 执行
SHOW GRANTS FOR 'app_user'@'10.0.2.%';，确认含TRIGGER权限（MySQL 8.0+ 不再包含在ALL PRIVILEGES中） - 别忽略
sql_log_bin = 0：某些 ORM 或连接池默认关闭 binlog，会导致触发器逻辑被跳过，查SELECT @@sql_log_bin;确认值为 1
SHOW WARNINGS 是唯二能穿透这层黑盒的手段，其余全是干扰项。
