应优先执行 SHOW ERRORS LIMIT 1 查看精准错误信息，因其返回最贴近问题根源的错误码和消息；若为空则说明是逻辑中断而非SQL异常。
触发器报错时，为什么不能只看客户端提示
MySQL 触发器执行失败，客户端（比如 Workbench 或 Navicat）常只显示模糊错误，例如 ERROR 1422 或直接静默失败。这是因为触发器内部的错误被事务层吞掉了一层，而客户端日志又容易截断或延迟刷新。真正有效的错误信息藏在服务器端最近一次语句的上下文中，不是在“Messages”面板里，而是在 SHOW ERRORS LIMIT 1 的输出中。
执行引发触发器的 DML 后，**立刻**运行该命令，它会返回最贴近问题根源的错误码和消息。如果 SHOW ERRORS 返回空，说明错误没触发 SQL 异常，而是逻辑中断——比如 SELECT ... INTO @var 查不到数据导致变量为 NULL，后续计算出错但没报异常。
怎样用日志表捕获 NEW 和 OLD 的实际值
建一张轻量级日志表是调试触发器最直接的方式，关键是让它不干扰主流程、不因自身失败拖垮原事务。推荐用 InnoDB 引擎，字段类型要足够宽（比如 LONGTEXT），避免因超长截断误判为 NULL。
- 日志表必须提前建好：
CREATE TABLE debug_log (id BIGINT AUTO_INCREMENT PRIMARY KEY, ts DATETIME, table_name VARCHAR(64), event_type VARCHAR(10), new_data JSON, old_data JSON) ENGINE=InnoDB; - 在触发器开头插入日志：例如
INSERT INTO debug_log (ts, table_name, event_type, new_data, old_data) VALUES (NOW(), 'users', 'UPDATE', JSON_OBJECT('id', NEW.id, 'name', NEW.name), JSON_OBJECT('id', OLD.id, 'name', OLD.name)); - 注意：不要对
TEXT/BLOB类型字段直接拼接，如CONCAT(OLD.content, ' deleted')在某些 MySQL 版本下可能返回NULL；改用IFNULL(OLD.content, '')包裹 -
NEW和OLD不是变量，不能赋值或声明，只能读取字段；列名含空格或关键字时必须加反引号，例如NEW.`order status`
BEFORE 还是 AFTER？写日志的位置决定你能看到什么
在 BEFORE UPDATE 中记录 OLD 和 NEW，能看到修改前后的原始值；但在 AFTER 阶段，NEW 已写入磁盘，部分字段（如自增 ID）才可安全读取。不过 AFTER 触发器里写日志有个硬限制：如果日志表写入失败（比如字段超长、权限不足），整个原事务会回滚——这反而掩盖了原本想查的问题。
所以调试阶段优先用 BEFORE，且确保日志语句放在触发器最前面。这样即使后续逻辑崩溃，至少能确认触发器是否执行、NEW/OLD 是否如预期加载。
-
BEFORE INSERT：可用NEW.col做清洗或默认值填充，但不能改自增主键（SET NEW.id = UUID()在INT AUTO_INCREMENT上会报ERROR 1362） -
BEFORE UPDATE：可对比OLD.col != NEW.col，但要用而非!=，避免NULL比较失效 -
AFTER INSERT：此时NEW.id是真实生成的自增值，适合记录关联日志；但不能再干预数据
模拟触发逻辑时，如何正确替换 NEW 和 OLD
触发器没法单步调试，也没法 PRINT 或 RAISE，唯一可靠方式是把触发器内语句拆出来，在相同数据状态下手动重跑。重点在于还原 NEW 和 OLD 的值——它们不是变量，不能直接传参，得靠临时变量模拟。
例如原触发器有 UPDATE orders SET status = 'shipped' WHERE id = NEW.order_id;，调试时应先设变量：SET @new_order_id = 123;，再执行等效语句：UPDATE orders SET status = 'shipped' WHERE id = @new_order_id;。每条语句后加 SELECT @debug_var AS debug; 查中间状态。
- 别写
SELECT * FROM OLD——OLD和NEW不是表，不能出现在FROM子句，否则报Table 'xxx' doesn't exist - 跨库操作需用完整限定名，如
INSERT INTO other_db.audit_log (...) VALUES (...);，且定义触发器的用户必须有目标库写权限 - 检查
sql_mode差异：不同环境可能开启STRICT_TRANS_TABLES，导致隐式转换失败，而本地测试时没开，现象不一致
调试触发器最耗时的地方往往不是语法错误，而是 NEW/OLD 的生命周期理解偏差——比如在 AFTER 里试图改 NEW，或用 != 比较可能为 NULL 的字段。这些细节不会报错，但会让日志看起来“值没变”“字段为空”，实际是逻辑绕过去了。
