on duplicate key update 未生效主因是缺少primary key或unique约束；仅唯一键冲突才触发更新，普通index无效；update中应使用values(col)引用本次插入值，避免误用原字段名。
ON DUPLICATE KEY UPDATE 为什么没生效
常见现象是执行后数据没变，甚至报错 ERROR 1062 (23000): Duplicate entry。根本原因通常是表里没有定义 PRIMARY KEY 或 UNIQUE 约束——MySQL 只有在插入时触发唯一键冲突，才会走 ON DUPLICATE KEY UPDATE 分支。
- 检查是否真有唯一索引：
SHOW CREATE TABLE your_table;，确认某列带UNIQUE或是主键 - 注意：普通
INDEX不行，必须是UNIQUE KEY或PRIMARY KEY - 复合唯一索引也支持，但冲突必须命中整个索引列组合，单列重复不触发
- 如果用的是自增主键，仅靠主键重复才能触发；但通常你希望按业务字段（如
email）去去重，那就得给email加UNIQUE
INSERT ... ON DUPLICATE KEY UPDATE 的字段赋值陷阱
更新子句里的值默认不能直接引用原字段做计算，比如想让计数器 +1，不能写 count = count + 1 —— 实际可以，但容易误写成 count = count + 1 却忘了加 VALUES() 函数包裹新值，导致语义混淆。
- 插入值优先用
VALUES(col_name)引用本次 INSERT 中该列的值，例如：UPDATE name = VALUES(name), updated_at = NOW() - 要自增字段，写
counter = counter + 1是合法的，它读的是当前行旧值 - 别混用：不要写
name = name（等于没更新），也不要写name = 'xxx'同时又漏掉其他必填列，UPDATE 部分只改列出的字段 - 如果 INSERT 部分用了
DEFAULT或表达式（如NOW()），VALUES(col_name)仍能取到计算后的结果
REPLACE INTO 和 INSERT ... ON DUPLICATE KEY UPDATE 的本质区别
看起来都能“存在就更新”，但 REPLACE INTO 是删再插，会引发主键变更、外键级联、触发器重复执行、自增 ID 跳号等问题；而 INSERT ... ON DUPLICATE KEY UPDATE 是原地更新，更轻量、更可控。
-
REPLACE INTO在遇到唯一冲突时，先DELETE匹配行，再INSERT新行 —— 这意味着：自增 ID 会+1，哪怕最终数据一样 - 如果有
ON DELETE CASCADE外键，REPLACE会触发级联删除，ON DUPLICATE KEY UPDATE完全不会 - 如果有
BEFORE/AFTER UPDATE触发器，只有后者能触发；REPLACE触发的是DELETE和INSERT对应的触发器 - 性能上，后者通常更快，尤其在大表、有多个索引或触发器时
批量 upsert 时 VALUES() 函数怎么对应多行
一次插入多行时，VALUES(col_name) 默认指向“当前正在处理的那行”的值，不是第一行，也不是随机一行 —— 这点很关键，否则批量更新会错乱。
- 示例：
INSERT INTO t(a,b) VALUES (1,10),(2,20) ON DUPLICATE KEY UPDATE b = VALUES(b);→ 冲突时，a=1 的行 b 更新为 10，a=2 的行 b 更新为 20 - 不能跨行引用，比如不能用
b = VALUES(a)（除非 a 和 b 是同一行里的列） - 如果某列在 INSERT 中没出现（比如用
DEFAULT），VALUES(col)返回 NULL，需留意是否导致非空约束失败 - 批量操作下，每行独立判断冲突、独立执行 UPDATE，互不影响
最常被忽略的一点：ON DUPLICATE KEY UPDATE 不会触发 INSERT 触发器里的 NEW 值逻辑，UPDATE 部分走的是 UPDATE 触发器路径；如果你依赖触发器生成某些值，得确保 UPDATE 触发器也覆盖了相同逻辑。
