BEFORE触发器中SET NEW.col未生效，须确认使用BEFORE INSERT/UPDATE时机，且字段允许NULL或无DEFAULT冲突、非主键/唯一键、满足类型与长度约束；AFTER中修改NEW.col无效。
BEFORE触发器里SET NEW.col没生效？检查时机和字段约束
必须用 BEFORE INSERT 或 BEFORE UPDATE，AFTER 里改 NEW.col 永远无效——它只是只读快照，不是可修改的输入载体。常见现象是写了 SET NEW.created_at = NOW(); 却发现字段仍为空或为默认值。
-
NEW只在BEFORE INSERT和BEFORE UPDATE中可写；BEFORE DELETE里只有OLD可用，NEW根本不存在 - 目标字段必须允许
NULL，或没有DEFAULT冲突（比如已有DEFAULT CURRENT_TIMESTAMP，再在触发器里赋值会静默失败） - 不能改主键或唯一键字段，否则可能触发
ERROR 1062（重复键） - 赋的值要满足约束：把
NEW.phone设成 20 位字符串，而字段定义是VARCHAR(11)，会报ERROR 1406
一执行就报 ERROR 1442：Can't update table 'xxx'？别碰原表
这是 MySQL 硬限制：触发器里任何对当前表的 UPDATE、INSERT、DELETE 都会立刻崩，哪怕只改一行、哪怕封装进存储过程也一样。错误不是锁导致的，是执行栈保护机制直接拦截。
- 典型错误写法：
UPDATE orders SET updated_at = NOW() WHERE id = NEW.id; - 临时表不是万能解：不能在触发器内执行
CREATE TEMPORARY TABLE（语法报错），必须提前建好 - 真正安全的替代：用
SET NEW.updated_at = NOW();（轻量、原子）；或把逻辑移到应用层，在INSERT前算好值再提交 - 如果非得数据库闭环，用
EVENT定时轮询临时表，而不是在触发器里直接操作原表
插入失败但没报错？查 NULL 和 NOT NULL 冲突
触发器里调函数返回 NULL，又赋给 NOT NULL 字段，就会静默卡在 ERROR 1048：Column 'xxx' cannot be null。这不是触发器语法错，是约束拦截了数据写入。
- 常见场景：
SET NEW.price = get_default_price();，而get_default_price()在无匹配规则时返回NULL，但price字段不允许为空 - 必须兜底：
SET NEW.price = IFNULL(get_default_price(), 0); - 用
SELECT ... INTO @var时更危险：查不到结果，@var自动变NULL，后续判断全失效；务必加ROW_COUNT() > 0校验 - 日志表字段也要检查：比如
operation_params VARCHAR(255) NOT NULL，但CONCAT()里拼了OLD.name（为NULL），整个字段就变NULL，插入直接失败
怎么确认触发器到底跑没跑？别靠 SELECT 输出
MySQL 触发器不支持 SELECT 输出到客户端，也不写 error log，所谓“没反应”大概率是根本没触发，或逻辑被静默跳过。
- 最可靠验证方式：建一张调试日志表，触发器开头插一条记录，例如
INSERT INTO trigger_debug_log (tbl, action) VALUES ('orders', 'BEFORE_INSERT'); - 报错后立刻执行
SHOW ERRORS LIMIT 1，它比客户端提示更准；如果返回空，说明错误发生在内部逻辑中断（如SELECT INTO查不到） - 调试时别用复杂子查询：先单独执行触发器里的子查询，确认有结果、类型匹配、不返回
NULL - 多个触发器共存时，用
SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'your_table'查清顺序和类型，ALTER TABLE your_table DISABLE TRIGGER trigger_name可临时禁用单个（MySQL 8.0+）
实际写触发器时，最容易被忽略的是字段级约束与 NEW 可写性的耦合关系——不是语法对了就能跑通，而是每一步赋值都要经受表结构的二次校验。
