MySQL用INSERT ... ON DUPLICATE KEY UPDATE、PostgreSQL用INSERT ... ON CONFLICT DO UPDATE、SQL Server用MERGE实现upsert，均需预先建立唯一约束，且各数据库语法细节和常见错误不同，高并发下应避免先查后插的老套路。
MySQL 中用 INSERT ... ON DUPLICATE KEY UPDATE 最直接
如果你的表有主键或唯一索引（比如 id 或 email），这是最简洁、原子性最强的做法。它一条语句搞定“存在则更新，不存在则插入”，不依赖存储过程也能实现逻辑。
常见错误是没建唯一约束就用这个语法——会直接插入两条重复数据，或者报错但没触发更新。务必先确认字段上有 UNIQUE 或 PRIMARY KEY 约束。
INSERT INTO users (id, name, email) VALUES (1, 'Alice', 'a@b.com') ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email);-
VALUES(name)表示 INSERT 子句中对应位置的值，不是变量名，别写成name = name（那会把字段设成自己当前值） - 如果更新字段多，注意不要漏掉
VALUES()包裹，否则可能误赋 NULL 或默认值
PostgreSQL 用 INSERT ... ON CONFLICT DO UPDATE
PostgreSQL 不支持 ON DUPLICATE KEY UPDATE，必须用 ON CONFLICT 显式指定冲突列。语法稍长，但更明确。
容易踩的坑是写错冲突目标：比如只写了 ON CONFLICT 没跟 ON CONFLICT (email)，会报错；或者冲突列没建唯一索引，同样不生效。
INSERT INTO users (id, name, email) VALUES (1, 'Bob', 'b@c.com') ON CONFLICT (email) DO UPDATE SET name = EXCLUDED.name;-
EXCLUDED是 PostgreSQL 关键字，代表本次想插入但被冲突挡住的那行数据，类比 MySQL 的VALUES() - 如果冲突基于联合唯一索引（如
(tenant_id, code)），ON CONFLICT (tenant_id, code)必须完全匹配索引定义顺序
SQL Server 用 MERGE 语句，但要注意事务和权限
MERGE 是 SQL Server 原生支持 upsert 的方式，但语法复杂、易出错，且在某些版本中对并发敏感（比如未加 HOLDLOCK 可能导致重复插入）。
典型问题是没写 WHEN NOT MATCHED THEN INSERT 的完整列列表，或 INSERT 和 VALUES 字段数不一致，直接报错。
- 必须为
INSERT明确列出所有非 NULL 列（包括标识列若要显式插入需先SET IDENTITY_INSERT ON） - 推荐加
WITH (HOLDLOCK)提示，避免并发下判断“不存在”后、真正插入前被别人抢先插入：FROM users WITH (HOLDLOCK) -
MERGE执行后@@ROWCOUNT返回的是总影响行数（insert + update），不能直接区分类型，需要额外逻辑判断
真要写存储过程？优先封装 INSERT ... ON CONFLICT 而非手写 IF EXISTS
很多人以为“写存储过程”就得先 SELECT COUNT(*) 再 IF 分支，这在高并发下大概率出错：两次查询之间可能有其他事务插入同 key 数据，造成主键冲突或脏读。
除非业务强要求在 upsert 前做额外校验（比如检查状态字段是否允许更新），否则没必要在存储过程中拆成两步。直接把上面任一数据库原生 upsert 语句包进 CREATE PROCEDURE 更安全、更高效。
- MySQL 存储过程里直接写
INSERT ... ON DUPLICATE KEY UPDATE即可，无需DECLARE变量判断 - SQL Server 若坚持用
IF EXISTS，至少给SELECT加UPDLOCK, HOLDLOCK锁提示，否则就是埋雷 - 所有数据库中，存储过程参数传入时，注意字符串参数是否带空格或 NULL——
NULL在唯一索引里不参与冲突判定，可能导致意外插入
