不能，触发器不能也不该自动合并重复学生档案；它仅能拦截重复插入（如通过唯一索引或BEFORE INSERT触发器报错），而合并逻辑须由应用层或ETL任务处理，否则易引发死锁、递归、外键异常等问题。
触发器能自动合并重复学生档案吗？不能，也不该
触发器不是数据清洗工具，它无法可靠地“合并”两条已存在的重复记录。SQL 触发器（如 BEFORE INSERT 或 BEFORE UPDATE）只能干预**当前正在插入或更新的那一条语句**，不能安全地执行跨行 UPDATE + DELETE 组合操作——这会引发死锁、递归触发、或违反约束（比如外键引用被删行），尤其在并发写入时几乎必然出错。
真正可行的做法是：用触发器**阻止重复插入**，把“合并”逻辑交给应用层或定时 ETL 任务处理历史重复数据。
如何用 BEFORE INSERT 触发器拦截重复学生（按身份证号）
假设表 students 有字段 id_card（唯一）、name、phone，你想在插入新记录前检查是否已有相同 id_card 存在：
- PostgreSQL 示例（支持
RAISE EXCEPTION）：CREATE OR REPLACE FUNCTION check_duplicate_student() RETURNS TRIGGER AS $$ BEGIN IF EXISTS (SELECT 1 FROM students WHERE id_card = NEW.id_card) THEN RAISE EXCEPTION '学生身份证 % 已存在', NEW.id_card; END IF; RETURN NEW; END; $$ LANGUAGE plpgsql; <p>CREATE TRIGGER prevent_duplicate_student BEFORE INSERT ON students FOR EACH ROW EXECUTE FUNCTION check_duplicate_student(); - MySQL 注意：不支持在触发器中直接查询本表（会报
ERROR 1442），必须改用唯一索引 + 错误捕获方式替代 - 关键点：触发器只做“拒绝”，不改写
NEW字段；合并逻辑（如保留更全信息、取最新时间戳）必须由上层决定
为什么不能在触发器里 UPDATE + DELETE 合并？
常见错误尝试：BEFORE INSERT 中发现重复后，UPDATE 原有记录字段，再设 NEW := NULL 阻止插入。这在多数数据库中会失败：
- MySQL：触发器内对本表的 UPDATE 会触发另一个
BEFORE UPDATE，可能无限递归或报错 - PostgreSQL：允许但极易死锁——两个并发插入同一
id_card的事务，各自查到对方未提交的行，然后互相等待对方释放锁 - SQL Server：触发器中修改本表会激活其他触发器，且
INSERTED表不可修改，无法“转向”更新 - 所有场景下，外键约束都可能被破坏（比如原记录被删，而关联的
enrollments表还没同步处理）
真正该怎么做：分两步，各司其职
把校验和合并拆开，用合适工具做合适的事：
- 校验阶段：用唯一索引强制约束
id_card（比触发器更高效、更可靠）ALTER TABLE students ADD CONSTRAINT uk_id_card UNIQUE (id_card);
- 合并阶段：定期运行合并脚本（非触发器！），例如 PostgreSQL 的
MERGE或手动UPDATE ... FROM+DELETE：-- 先合并 phone/name 到主记录（取非空且更新的值） UPDATE students s1 SET phone = COALESCE(s1.phone, s2.phone), name = COALESCE(s1.name, s2.name) FROM students s2 WHERE s1.id_card = s2.id_card AND s1.id < s2.id; <p>-- 再删掉冗余副记录 DELETE FROM students s2 USING students s1 WHERE s2.id_card = s1.id_card AND s2.id > s1.id; - 应用层插入时捕获唯一约束异常（如
UNIQUE_VIOLATION或 MySQL 的1062），再主动查出已有记录 ID，调用合并 API
触发器的边界很窄：它只适合轻量、确定、无副作用的检查。一旦涉及多行变更、业务逻辑判断或外部依赖，就该退出舞台了。
