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 子句里有效，且容易和变量名混淆。
iWebShop是一款基于PHP语言及MYSQL数据库开发的B2B2C多用户开源免费的商城系统，系统支持自营和多商家入驻、集成微信商城、手机商城、移动端APP商城、三级分销、视频电商直播、微信小程序等于一体，它可以承载大数据量且性能优良，还可以跨平台，界面美观功能丰富是电商建站首选源码。iWebShop开源商城系统 v5.14 更新日志：新增商品编辑页面规格图片上传优化商品详情页面规格图片与主图切
实操建议：
-
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 又是另一套关键字。更麻烦的是，应用层如果缓存了主键或唯一键生成逻辑，而数据库侧约束没同步更新，这类问题往往在线上跑几天才暴露。
