INSERT触发器只能用NEW，OLD未定义；UPDATE中NEW和OLD需谨慎比对，未更新字段按默认值处理；DELETE触发器仅可用OLD。
INSERT触发器里只能用NEW，不能用OLD
INSERT操作没有“旧行”，所以OLD在INSERT触发器中是未定义的，直接引用会报错：ERROR 1327 (42000): Undeclared variable: OLD。此时所有字段值都来自NEW——它代表即将插入的那行数据。
常见误用场景：想在INSERT触发器里做“如果某字段为空则自动补默认值”，结果写成IF OLD.name IS NULL THEN ...，这必然失败。
-
NEW是只读的，但可在BEFORE INSERT中赋值（如SET NEW.created_at = NOW()） -
NEW字段名必须严格匹配表结构，大小写敏感（取决于系统变量lower_case_table_names） - 若插入语句用了列别名或计算字段（如
INSERT INTO t VALUES (1, @x + 1)），NEW仍反映最终写入值，不是原始表达式
UPDATE触发器中NEW和OLD都要谨慎比对
OLD是更新前的原值，NEW是更新后的新值。两者字段名一致，但值可能不同。关键陷阱在于：即使SQL里只更新了部分列，NEW中未指定的字段仍会被设为DEFAULT或NULL（取决于表定义），而非保留原值。
例如表users(id INT, name VARCHAR(50) DEFAULT 'anon', email VARCHAR(100))，执行UPDATE users SET name = 'Alice' WHERE id = 1，在触发器中NEW.email会是NULL（如果该列允许NULL且没显式赋值），而不是OLD.email的原值。
- 判断字段是否真被修改，应写
IF OLD.col_name != NEW.col_name，而非IF NEW.col_name IS NOT NULL - 注意
!=对NULL比较返回UNKNOWN，建议用NOT (OLD.col_name NEW.col_name)（是安全等于运算符） -
BEFORE UPDATE中可修改NEW，但不能修改OLD；AFTER UPDATE中两者都只读
DELETE触发器里只有OLD可用，NEW会报错
DELETE不产生新行，所以NEW在DELETE触发器中不可用，引用即报ERROR 1327。所有待删数据都在OLD里。
典型用途是归档或日志记录，比如把删掉的行插入到users_archive表。这时要注意：如果目标表结构与原表不完全一致（如多了deleted_at字段），需显式列出字段名，避免INSERT ... SELECT *失败。
-
OLD在BEFORE DELETE和AFTER DELETE中都有效且只读 - 若原表有外键级联删除，触发器看到的
OLD仍是当前行，不会包含被级联删掉的关联行 - 不要在
DELETE触发器里再删同一张表（除非明确禁用触发器递归），否则可能死锁或报错ERROR 1442
跨存储引擎或含自增主键时，NEW的行为有隐含限制
InnoDB和MyISAM对NEW.id（自增主键）的处理略有差异：在BEFORE INSERT中给NEW.id赋值，InnoDB会跳过自增逻辑直接使用该值；而MyISAM在某些旧版本中可能忽略该赋值。更隐蔽的问题是，在INSERT ... ON DUPLICATE KEY UPDATE引发的触发器中，MySQL不会为“update分支”触发BEFORE INSERT，而是走BEFORE UPDATE——这意味着你以为能用NEW初始化的字段，实际根本没机会设置。
- 依赖
NEW.id生成关联ID（如订单号拼接）时，务必在BEFORE INSERT中检查NEW.id IS NULL，再决定是否SET NEW.id = ... - 触发器内调用
UUID()、NOW()等函数是安全的，但调用LAST_INSERT_ID()无意义——它返回的是外部语句的ID，不是触发器内部产生的 - 触发器中禁止使用
SELECT ... FOR UPDATE或任何显式事务控制语句，否则报ERROR 1382
最常被忽略的一点：触发器里的NEW和OLD不是独立副本，它们和当前行共享约束校验上下文。比如你在BEFORE INSERT里给NEW.email设了一个超长字符串，而字段定义是VARCHAR(50)，截断发生在触发器执行之后、实际插入之前——你无法在触发器里捕获这个隐式截断，也拿不到被截后的值。需要校验，就得在触发器里手动CHAR_LENGTH(NEW.email) > 50提前判断。
