before insert触发器中可用set new.field修改字段值，因new是可写临时对象，能直接影响入库数据；after insert中new只读，赋值会报错。
BEFORE INSERT 触发器中用 SET NEW.field 修改字段值
能直接改，且必须在 BEFORE INSERT 里做——AFTER INSERT 中 NEW 只读，改了也没用，还会报错。
关键点是：触发器执行时，数据还没真正写入表，NEW 是一个可写的临时行对象，SET NEW.email = LOWER(NEW.email) 这类赋值会直接影响最终入库的值。
-
DELIMITER必须改（比如设成//），否则遇到分号就提前结束，导致语法错误 - 只能对当前触发事件涉及的字段赋值；给不存在的字段
SET NEW.nonexistent = 'x'会报错 - 如果字段定义为
NOT NULL且没默认值，而你在触发器里把它设为NULL，插入会失败 - 多个字段连续赋值要分行写，不能写成
SET NEW.a=1, NEW.b=2（MySQL 不支持这种逗号分隔的批量赋值）
常见格式化场景与对应函数组合
不是所有清洗都适合放触发器里，但轻量、确定性高的转换很稳：邮箱小写、去空格、日期标准化、价格自动计算等。
- 邮箱统一小写 + 去首尾空格：
SET NEW.email = LOWER(TRIM(NEW.email)) - 用户名首字母大写、其余小写（需配合
SUBSTRING）：SET NEW.name = CONCAT(UPPER(LEFT(TRIM(NEW.name), 1)), LOWER(SUBSTRING(TRIM(NEW.name), 2))) - 电话号码只留数字：
SET NEW.phone = REGEXP_REPLACE(NEW.phone, '[^0-9]', '')（MySQL 8.0+ 才支持REGEXP_REPLACE） - 自动补全缺失的
created_at：SET NEW.created_at = IFNULL(NEW.created_at, NOW()) - 用另一字段兜底填空：
SET NEW.nickname = IFNULL(NEW.nickname, NEW.username)
为什么不能在 AFTER INSERT 里改 NEW 字段
因为 AFTER INSERT 触发时，数据已经落盘，NEW 仅作只读引用。此时执行 SET NEW.xxx = ... 不会改变已插入的数据，MySQL 会直接报错：ERROR 1362 (HY000): Updating of NEW row is not allowed in after trigger。
如果你真需要“插入后再改”，得走两步：先 AFTER INSERT 读出 NEW.id，再 UPDATE 自己这张表——但这会额外引发一次更新操作，可能再次触发其他 UPDATE 触发器，容易形成循环或性能抖动。
- 想改刚插进去的值 → 用
BEFORE INSERT - 想记录日志或通知下游 → 用
AFTER INSERT，但别碰NEW赋值 - 想根据新数据更新关联表 →
AFTER INSERT+INSERT INTO other_table VALUES(...)是安全的
容易被忽略的坑：NULL 处理和字符集隐式转换
触发器里看似简单的 TRIM(NEW.field) 或 LOWER(NEW.field)，在字段为 NULL 时会返回 NULL，而不是空字符串。如果业务逻辑依赖非空值，不加判断就会埋雷。
- 别直接
TRIM(NEW.email)，应写成TRIM(IFNULL(NEW.email, '')) -
LOWER()对中文、emoji 等无效，且若字段字符集是utf8mb4但排序规则是utf8mb4_bin，LOWER可能不生效（得用utf8mb4_0900_as_cs类规则） - 触发器内函数调用不走索引，纯属内存计算，大数据量高频插入时注意 CPU 消耗
- 调试困难：触发器出错不会在应用层直接暴露，常表现为“插入失败但没明确报错”，建议搭配
SIGNAL主动抛异常定位问题
最麻烦的其实是测试覆盖——不同字符、空值、超长值、特殊符号混在一起时，SET NEW.field 的行为未必如你所想，上线前务必用真实数据样本跑一遍边界 case。
