mysql中old仅在update和delete触发器中可用且只读，insert中引用会报error 1363；字段名须与表定义完全一致（含大小写、空格、下划线），否则报unknown column；before update是安全获取真实旧值的唯一时机，null比较需用is null显式判断。
MySQL里只能用OLD，且只在UPDATE和DELETE中有效
INSERT触发器里访问OLD会直接报错：ERROR 1363 (HY000): There is no OLD row in on INSERT trigger。UPDATE和DELETE触发器中，OLD是只读伪记录，不能赋值——写SET OLD.id = 1会报ERROR 1362。字段名必须和表定义完全一致：大小写、下划线、空格、关键字一个都不能错。比如字段是`order status`（含空格），就得写OLD.`order status`；写成OLD.order_status或OLD.orderstatus都会触发Unknown column 'OLD.xxx' in 'field list'。
BEFORE UPDATE才是读取完整旧值的唯一安全时机
AFTER UPDATE触发器里OLD虽可读，但此时原行已提交，若事务回滚，你记下的“旧值”可能根本没生效；而BEFORE UPDATE中OLD反映的是真实待改前状态，且能配合NEW做字段级比对。常见错误是用OLD.col = NEW.col判断是否变更——当字段为NULL时，该表达式返回UNKNOWN而非TRUE/FALSE，导致条件失效。正确写法是：(OLD.col IS NULL) != (NEW.col IS NULL) OR OLD.col != NEW.col。如果字段类型是TEXT或BLOB，某些MySQL 5.7版本在触发器里对OLD.content调用CONCAT()可能返回NULL，这不是OLD失效，而是大字段上下文处理异常。
SQL Server用deleted表，不是OLD
SQL Server没有OLD/NEW关键字，而是靠deleted（含旧值）和inserted（含新值）两张内存伪表。UPDATE触发器中，必须用INNER JOIN关联主键才能确保一一对应：SELECT d.id, d.name AS old_name, i.name AS new_name FROM deleted d INNER JOIN inserted i ON d.id = i.id。千万别用SELECT TOP 1或ORDER BY (SELECT NULL)强行取一行——批量更新时结果不可靠。还要注意：单行操作只是巧合，deleted和inserted都可能含多行，必须按主键JOIN，不能假设“当前行”存在。
PostgreSQL里OLD是RECORD类型，不能直接点字段
PostgreSQL的OLD和NEW是RECORD类型，直接写OLD.id会报错“record type has no field”。必须先声明变量，再用SELECT ... INTO赋值：DECLARE v_name TEXT; BEGIN SELECT name INTO v_name FROM users WHERE id = OLD.id;。或者用jsonb_build_object('id', OLD.id, 'name', OLD.name)构造结构化快照。别依赖OLD IS DISTINCT FROM NEW判断变更——它对NULL不敏感，可能漏掉NULL → ''这类实际变化。触发器函数末尾必须显式RETURN OLD（DELETE）或RETURN NEW（INSERT/UPDATE），否则整个事务会回滚并报trigger procedure did not return a value。
真正容易被忽略的是：日志里某字段显示为空，第一反应常是“OLD没拿到”，但大概率是字段定义为TEXT类型，加上MySQL版本或上下文限制导致隐式转换失败——得先确认字段类型和MySQL版本行为，而不是急着改触发器逻辑。
