不能在INSERT触发器中可靠判断主键/唯一键冲突，因并发下SELECT COUNT(*)存在竞态，且BEFORE INSERT触发器无法感知约束检查结果；应改用INSERT ... ON DUPLICATE KEY UPDATE（MySQL）或ON CONFLICT（PostgreSQL）等数据库原生UPSERT语法处理冲突。
INSERT 触发器里怎么判断主键/唯一键冲突
直接在 INSERT 触发器里查 SELECT COUNT(*) 不可靠——因为并发插入时，两次触发器可能同时查不到对方还没提交的数据，结果都走插入逻辑，最终违反唯一约束报错。真正能捕获冲突的时机，是在触发器执行前、语句级约束检查之后，但标准 SQL 的 BEFORE INSERT 触发器无法感知这个结果。
所以实际做法不是“在触发器里拦截冲突”，而是：把插入逻辑改写成 INSERT ... ON CONFLICT（PostgreSQL）或 INSERT ... ON DUPLICATE KEY UPDATE（MySQL），让数据库引擎自己处理。触发器只用于补充逻辑，比如记录日志、更新统计字段等。
- PostgreSQL 必须用
ON CONFLICT DO UPDATE，不能依赖触发器做“查再插” - MySQL 5.7+ 支持
ON DUPLICATE KEY UPDATE，但注意它只响应PRIMARY KEY或UNIQUE约束冲突，普通索引无效 - SQL Server 没有原生语法，得用
MERGE语句替代，且需显式指定WHEN MATCHED THEN UPDATE
触发器里调用 UPDATE 会引发递归或死锁吗
会。如果在 BEFORE INSERT 触发器里对同一张表执行 UPDATE，而该表又定义了 UPDATE 触发器，就可能触发递归；更危险的是，在事务中先 INSERT 再 UPDATE 同一行，可能因锁顺序不同导致死锁（尤其高并发时）。
正确做法是避免在触发器里写 DML 操作。如果真要“转为更新”，应该：
- 用
INSTEAD OF INSERT触发器（仅 SQL Server / PostgreSQL 的视图支持，普通表不支持） - 或把业务逻辑上移到应用层，用
UPSERT语句统一处理 - 若必须用触发器做副作用（如更新关联计数器），确保
UPDATE目标是另一张表，且加WHERE条件避免全表扫描
MySQL 的 ON DUPLICATE KEY UPDATE 怎么安全更新非冲突字段
ON DUPLICATE KEY UPDATE 默认只更新指定列，但容易忽略两个坑：一是没写 VALUES(col) 会导致用旧值覆盖自身，二是时间戳字段若设了 DEFAULT CURRENT_TIMESTAMP，不显式赋值就不会刷新。
INSERT INTO users (id, name, email, updated_at) VALUES (123, 'Alice', 'a@b.c', NOW()) ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email), updated_at = NOW();
注意：VALUES(name) 表示本次 INSERT 语句中的值，不是当前行的值；updated_at = NOW() 是显式刷新时间戳，否则它会保持原值。
- 不要写
name = name，这等于没更新 - 涉及计算字段（如
counter = counter + 1），要确认是否允许并发重复累加 - 如果唯一键是组合键（如
(user_id, day)），冲突检测只看这两个字段，其他字段照常插入或更新
PostgreSQL 中如何在 UPSERT 后让触发器生效
PostgreSQL 的 ON CONFLICT DO UPDATE 默认跳过所有触发器（包括 BEFORE UPDATE 和 AFTER UPDATE），除非显式声明 DO UPDATE SET ... WHERE ... 并配合 RETURNING 手动触发逻辑。
常见解法是：用 RETURNING 获取是否发生更新，再在应用层决定是否补发通知或调用函数：
INSERT INTO orders (id, status, amount) VALUES (456, 'pending', 99.99) ON CONFLICT (id) DO UPDATE SET status = EXCLUDED.status, amount = EXCLUDED.amount RETURNING id, (xmax = 0) AS is_insert;
EXCLUDED 是 PostgreSQL 关键字，代表本次想插入但被拒绝的那行数据；xmax = 0 是判断是否为新插入行的小技巧（仅限堆表，不适用于分区表或 AO 表）。
真正需要触发器行为的场景（如审计日志），建议放弃在 UPSERT 中依赖触发器，改为在应用层统一调用一个存储过程封装“尝试插入，失败则更新，然后记日志”全流程。
触发器不是万能胶，它解决不了原子性边界之外的问题。把冲突处理逻辑塞进触发器，往往让问题更隐蔽——尤其是当别人修改表结构、加新唯一索引时，原有触发器不会自动适配。
