MySQL中INSERT...ON DUPLICATE KEY UPDATE需确保唯一索引生效，UPDATE中避免NULL计算错误、禁止引用未插入列；REPLACE INTO性能差在删插两步导致ID跳变、触发器重复执行及锁更久；批量操作须用参数化查询防注入，PostgreSQL则需显式指定ON CONFLICT目标与EXCLUDED语法。
INSERT ... ON DUPLICATE KEY UPDATE 怎么写才不踩主键冲突的坑
MySQL 里想“有则更新、无则插入”，INSERT ... ON DUPLICATE KEY UPDATE 是最常用解法，但很多人一用就报 Column 'id' cannot be null 或直接跳过更新——根本原因是没确认唯一约束是否真正生效。
实操建议：
- 必须确保表上存在
UNIQUE索引或PRIMARY KEY，仅靠业务逻辑“认为”某字段唯一是无效的；ON DUPLICATE KEY UPDATE只响应索引冲突，不校验逻辑唯一性 -
UPDATE子句里避免写col = col + 1这类表达式，如果原值为NULL，结果会变成NULL，而不是你预期的1；改用col = IFNULL(col, 0) + 1 - 不要在
UPDATE部分引用未在INSERT列表中出现的列（比如INSERT INTO t(a) VALUES(1) ON DUPLICATE KEY UPDATE b = a + 1），MySQL 会报Unknown column 'a' in 'field list'
REPLACE INTO 和 INSERT ... ON DUPLICATE KEY UPDATE 的性能差在哪
REPLACE INTO 看似更简洁，但它底层是「删+插」：先尝试插入，冲突时删掉旧行再插新行。这会导致自增 ID 跳变、触发器重复执行、外键级联动作被意外触发——不是语义等价，而是行为完全不同。
实操建议：
- 只要表有自增主键，
REPLACE INTO就可能让id值突增，下游依赖自增顺序的代码会出问题 - 如果表上有
ON DELETE CASCADE的外键，REPLACE INTO会真实触发删除动作，可能误删关联记录；而INSERT ... ON DUPLICATE KEY UPDATE完全不涉及 DELETE - 高并发下，
REPLACE INTO的 delete+insert 两步操作持有更久的行锁，更容易引发锁等待；INSERT ... ON DUPLICATE KEY UPDATE在检测到冲突后直接走 update 路径，锁持有时间更短
批量 upsert 用 VALUES() 函数怎么避免 SQL 注入和类型错乱
批量插入/更新时，有人拼接 VALUES(1,'a'),(2,'b') ON DUPLICATE KEY UPDATE name = VALUES(name)，其中 VALUES(name) 是 MySQL 特殊函数，表示“本次 INSERT 中该列对应位置的值”。但它只在 ON DUPLICATE KEY UPDATE 子句里有效，且容易和变量名混淆。
实操建议：
-
VALUES(col)中的col必须是目标表的列名，不能是别名或表达式；也不能写成VALUES(t.col)（带表名前缀） - 如果批量数据里某列允许
NULL，但表定义是NOT NULL DEFAULT 'x'，VALUES(col)传入NULL会覆盖默认值——这是有意行为，不是 bug，需提前确认业务是否接受 - 绝对不要把用户输入直接拼进
VALUES()括号里；应统一用参数化查询（如mysql2的query(sql, params)），让驱动处理类型绑定；否则字符串里的单引号、反斜杠可能破坏 SQL 结构
PostgreSQL 怎么实现等效的 upsert（ON CONFLICT）
PostgreSQL 没有 ON DUPLICATE KEY UPDATE，对应的是 ON CONFLICT 语法，但触发条件、目标指定和排除逻辑更严格，稍不注意就报 ON CONFLICT DO UPDATE requires inference specification or constraint name。
实操建议：
- 必须显式指定冲突目标：
ON CONFLICT (user_id)（列名）、ON CONFLICT ON CONSTRAINT idx_user_email（唯一索引名），不能只写ON CONFLICT -
DO UPDATE SET后面不能引用未在INSERT列表中出现的列；若要引用原值，得用EXCLUDED.col（注意是EXCLUDED，不是VALUES） - 如果表有多个唯一约束，但只想对其中一个做 upsert，必须明确写出该约束或列组合，否则 PostgreSQL 不知道你指哪次冲突
upsert 看似简单，但跨数据库时连“冲突依据”都要重新对齐：MySQL 看索引，PostgreSQL 要显式声明，SQLite 又是另一套关键字。更麻烦的是，应用层如果缓存了主键或唯一键生成逻辑，而数据库侧约束没同步更新，这类问题往往在线上跑几天才暴露。
