AFTER触发器中修改NEW字段无效，因NEW在AFTER阶段仅为只读快照；必须用BEFORE INSERT/UPDATE，且需满足字段允许NULL、不违约束、不改主键等前提。
为什么 AFTER 触发器里改 NEW.column 没反应
因为 NEW 在 AFTER 阶段已只读，MySQL 不允许、也不生效。你写 SET NEW.status = 'done'; 语法能通过，但插入或更新后的数据仍是原值——它根本没机会参与写入流程。
常见错误现象：
-
SHOW CREATE TRIGGER显示是AFTER INSERT，却试图用SET NEW.created_at = NOW();填时间戳，结果字段为空或为默认值 - 触发器逻辑看似执行了（比如日志表有记录），但主表数据未被“修正”，误以为是赋值语句写错
根本原因：AFTER 的语义是“操作已完成”，NEW 此时只是快照，不是可干预的输入载体。
必须用 BEFORE，但不是所有 BEFORE 都安全
只有 BEFORE INSERT 和 BEFORE UPDATE 允许写 NEW 字段，且必须满足三个前提：
- 目标字段在表结构中允许
NULL或无默认值（否则可能和DEFAULT CURRENT_TIMESTAMP冲突） - 修改后值不违反约束（比如把
NEW.phone改成超长字符串，会触发ERROR 1406） - 不修改主键或唯一键字段导致重复冲突（例如
SET NEW.id = (SELECT MAX(id)+1 FROM t)）
示例（合法）：
CREATE TRIGGER set_default_status BEFORE INSERT ON orders FOR EACH ROW SET NEW.status = IF(NEW.status IS NULL, 'pending', NEW.status);
千万别在触发器里 UPDATE 同一张表
哪怕只改当前行，比如 UPDATE orders SET updated_at = NOW() WHERE id = NEW.id;，MySQL 会直接报错：Can't update table 'orders' in stored function/trigger because it is already used by statement...
这不是权限问题，是 MySQL 的硬性保护机制，防止隐式递归或事务不一致。
替代方案只有两个：
- 用
SET NEW.updated_at = NOW();（推荐，轻量、原子、可控） - 把逻辑移到应用层，由业务代码在
INSERT/UPDATE前计算好值再提交（更灵活，也更容易测试）
试图绕过（如用临时表、存储过程封装）只会增加复杂度，且无法解决根本限制。
NEW.id 在 BEFORE INSERT 中总是 NULL 或 0
即使字段是 AUTO_INCREMENT，在 BEFORE INSERT 里读 NEW.id 也拿不到将要生成的值——它还没被分配。依赖它做关联查询（比如 SELECT name FROM users WHERE id = NEW.id）必然查不到。
如果你需要基于自增 ID 做后续处理：
- 改用
AFTER INSERT触发器（此时NEW.id可读，但不能再写回） - 放弃触发器，用应用层获取
LAST_INSERT_ID()后主动补全 - 用 UUID 或业务生成 ID 替代自增，让 ID 在插入前就确定
这个限制容易被忽略，尤其当开发环境用了模拟 ID 的测试数据，上线后才暴露。
