在mysql insert触发器中，用new可访问刚插入行的字段值；before中可修改new字段以改写插入值，after中new只读，仅用于读取或关联操作。
MySQL触发器里怎么拿到刚插入的那条数据
在 INSERT 触发器中，用 NEW 就能直接访问新行字段——它不是变量，是只读的伪记录（pseudo-record），每个字段对应插入语句里的值。别试图给 NEW.column_name 赋值，会报错。
常见错误现象：ERROR 1362 (HY000): Updating of NEW row is not allowed in after trigger，说明你在 AFTER INSERT 里改了 NEW，或者误以为 NEW 是普通变量可重赋值。
-
NEW只在INSERT和UPDATE触发器中有效，DELETE里只能用OLD -
BEFORE INSERT中可以修改NEW.column_name，比如自动补全时间、转换大小写；AFTER INSERT中禁止修改 - 如果插入语句用了
INSERT ... SELECT，NEW仍按每行分别生效，不是整批处理
NEW.column_name 报 Unknown column 错误怎么办
这通常不是语法问题，而是字段名拼错了，或触发器定义时表结构已变但没同步更新触发器。MySQL 不会在创建触发器时校验字段是否存在，只有真正触发时才报错。
使用场景：你加了个新字段 status，然后在触发器里写 NEW.status，结果报错——先确认该字段确实在目标表中存在，且大小写与表定义完全一致（尤其在大小写敏感的文件系统上）。
- 执行
DESCRIBE table_name对照字段名，注意反引号不是必须的，但若字段含特殊字符或关键字，必须用`status` - 触发器中不能用别名，比如
INSERT INTO t (id, name) VALUES (1, 'a')，触发器里只能写NEW.id、NEW.name，不能写NEW.`name`（除非原字段名带空格或横线） - 如果表用了分区或临时表，
NEW行为不变，但需确保触发器绑定的是实际基表，而非视图
BEFORE 和 AFTER 中 NEW 的行为差异
核心区别就一条：只有 BEFORE INSERT 允许给 NEW.column_name 赋值，用于改写即将插入的值；AFTER INSERT 中 NEW 是只读快照，仅可用于读取或关联其他表操作。
性能影响：在 BEFORE 中做复杂计算（比如调用函数、查另一张大表）会拖慢插入本身，因为这些逻辑在事务内同步执行；AFTER 里虽不能改 NEW，但适合发通知、写日志、更新统计表等副作用操作。
-
BEFORE INSERT中给NEW.created_at = NOW()是安全且常见的，默认值或生成列（GENERATED COLUMN）也能替代，但触发器更灵活 -
AFTER INSERT中想“基于新值再插一条”，得用INSERT INTO log_table SELECT NEW.id, NEW.name, NOW()这类语句，不能写INSERT INTO log_table VALUES (NEW.id, ...)后再手动拼参数 - 跨引擎注意：如果目标表是 MyISAM，
AFTER触发器里不能操作 InnoDB 表并期望事务一致性——MyISAM 不支持事务
NEW 在多行 INSERT 中怎么工作
每行独立触发，NEW 每次都指向当前正在处理的那一行。不存在“批量获取所有 NEW”的方式，也没 NEWs 这种数组。
容易踩的坑：有人写 INSERT INTO t VALUES (1,'a'),(2,'b'),(3,'c')，然后以为触发器里能一次性拿到三行，结果发现日志只记了一条——其实是触发了三次，每次 NEW 不同，但如果你没在触发器里做循环或累积逻辑，就只会看到最后一行的效果（比如变量覆盖）。
- 不要在触发器里用用户变量（如
@counter := @counter + 1）来计数，因为多行插入时执行顺序不保证，且变量作用域可能跨行污染 - 如果真要聚合多行信息（比如插入后发汇总消息），得靠外部应用层控制，或改用事件驱动架构，触发器本身不适合这类聚合
- 批量插入性能敏感时，尽量避免在
BEFORE触发器里做 I/O 或网络调用，否则每行都卡一次
最常被忽略的一点：触发器里的 NEW 不包含默认值未显式指定的字段（哪怕建表时写了 DEFAULT CURRENT_TIMESTAMP），那些字段在 NEW 中就是 NULL，除非你用 BEFORE 显式赋值。这点和应用层 ORM 的“默认填充”逻辑完全不同。
