在业务系统中，不少核心表采用复合主键来唯一标识一条记录，例如订单明细表由订单编号与商品编号共同构成主键。当这类记录发生更新时，如果仅用单一字段判断逻辑，很容易忽略另一主键字段或关联业务字段的变化。mysql触发器可以在更新前后介入，通过映射多字段进行逐项比对，从而精确捕捉真正的变更点。
一、复合主键更新的常见误区
很多团队在写UPDATE触发器时，习惯用IF OLD.status <> NEW.status THEN这类条件。但当表的主键是(user_id, product_id)这种组合时，若程序误将某条记录的主键部分字段改掉，单列比对完全发现不了。更隐蔽的问题是，有的开发者直接在触发器里用OLD.id <> NEW.id，而id实际不存在，真正的主键列被忽略，导致日志缺失。
另一个误区是认为AFTER UPDATE触发器总能拿到最新数据，却没考虑同一事务内多次更新同一行的情况。触发器每执行一次更新都会再触发一次，若内部又做UPDATE，就会陷入递归。因此比对方案必须先明确：我们只关心哪些字段，以及是否在BEFORE阶段拦截。
二、映射多字段的比对模型
所谓映射多字段逻辑比对，就是把复合主键的每个列，以及需要监控的业务列，都列成一个映射清单。在触发器内部，依次判断OLD与NEW对应字段是否相等。只要有一个不等，就认为发生有效变更。这种模型可以用一个临时变量标记，避免写多层嵌套IF。
下面以订单明细表为例，主键为(order_no, sku_code)，同时监控price与quantity。我们建立一个变更日志表order_detail_log，结构包含原主键、新主键、变更字段名、旧值、新值。映射比对的核心是先比对主键字段，再比对业务字段，分别插入日志。
-- 变更日志表
CREATE TABLE order_detail_log (
id INT AUTO_INCREMENT PRIMARY KEY,
old_order_no VARCHAR(32),
old_sku_code VARCHAR(32),
new_order_no VARCHAR(32),
new_sku_code VARCHAR(32),
changed_col VARCHAR(32),
old_val VARCHAR(100),
new_val VARCHAR(100),
change_time DATETIME
);
-- BEFORE UPDATE触发器
DELIMITER $$
CREATE TRIGGER trg_order_detail_before_update
BEFORE UPDATE ON order_detail
FOR EACH ROW
BEGIN
-- 映射复合主键字段比对
IF OLD.order_no <> NEW.order_no THEN
INSERT INTO order_detail_log(old_order_no, old_sku_code, new_order_no, new_sku_code, changed_col, old_val, new_val, change_time)
VALUES(OLD.order_no, OLD.sku_code, NEW.order_no, NEW.sku_code, 'order_no', OLD.order_no, NEW.order_no, NOW());
END IF;
IF OLD.sku_code <> NEW.sku_code THEN
INSERT INTO order_detail_log(old_order_no, old_sku_code, new_order_no, new_sku_code, changed_col, old_val, new_val, change_time)
VALUES(OLD.order_no, OLD.sku_code, NEW.order_no, NEW.sku_code, 'sku_code', OLD.sku_code, NEW.sku_code, NOW());
END IF;
-- 映射业务字段比对
IF OLD.price <> NEW.price THEN
INSERT INTO order_detail_log(old_order_no, old_sku_code, new_order_no, new_sku_code, changed_col, old_val, new_val, change_time)
VALUES(OLD.order_no, OLD.sku_code, NEW.order_no, NEW.sku_code, 'price', OLD.price, NEW.price, NOW());
END IF;
IF OLD.quantity <> NEW.quantity THEN
INSERT INTO order_detail_log(old_order_no, old_sku_code, new_order_no, new_sku_code, changed_col, old_val, new_val, change_time)
VALUES(OLD.order_no, OLD.sku_code, NEW.order_no, NEW.sku_code, 'quantity', OLD.quantity, NEW.quantity, NOW());
END IF;
END$$
DELIMITER ;
三、避免误触发与递归更新
上述BEFORE UPDATE触发器只做日志记录，不对原表做写操作，因此不会引发递归。如果业务逻辑要求在主键变化时自动修正关联表，就需要在触发器里UPDATE别的表，而不是UPDATE当前表。一旦在触发器内写UPDATE order_detail SET ...，mysql会再次调用本触发器，造成栈溢出或死循环。
另外，NULL值比对要小心。mysql中NULL <> NULL的结果是NULL而非真，所以如果字段允许NULL，应使用IFNOT (OLD.col <=> NEW.col)这种空安全等号。改写后的比对片段如下：
-- 空安全比对示例
IF NOT (OLD.order_no <=> NEW.order_no) THEN
INSERT INTO order_detail_log(changed_col, old_val, new_val, change_time)
VALUES('order_no', OLD.order_no, NEW.order_no, NOW());
END IF;
通过<=>运算符，当两边都是NULL时返回真，一边NULL一边非NULL时返回假，正好符合我们捕捉变更的需求。配合复合主键的逐列映射，整体方案在真实高并发下单场景中表现稳定。
四、方案优缺点与适用边界
这种多字段映射比对方案的优点是逻辑直观，每个字段独立判断，方便后期扩展监控列。由于使用BEFORE UPDATE且不涉及原表回写，性能开销仅在于插入日志，可通过异步表或条件过滤进一步降低。缺点是需要手动维护字段清单，表结构变更时要同步修改触发器。
它适合强一致审计、数据血缘追踪的系统。若仅是缓存同步，建议把比对逻辑放到应用层，利用ORM的脏检查机制，避免数据库触发器难以调试的问题。总体而言，mysql触发器处理复合主键更新时，只要坚持逐字段映射与空安全比对，就能可靠落地多字段逻辑比对。