ON DUPLICATE KEY UPDATE 能实现“存在即更新”是因为它依赖唯一约束触发冲突处理机制：当INSERT遇到重复键错误（1062）时执行UPDATE，否则执行INSERT；前提是有UNIQUE或PRIMARY KEY约束且冲突列在其覆盖范围内。
ON DUPLICATE KEY UPDATE 为什么能实现“存在即更新”
MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE 不是语法糖，而是由唯一约束（UNIQUE 或 PRIMARY KEY）触发的冲突处理机制。它只在插入时遇到重复键错误（1062 Duplicate entry）才执行 UPDATE 分支，否则走纯 INSERT。关键前提是：表里必须有至少一个 UNIQUE 或 PRIMARY KEY 约束，且冲突字段要落在该约束覆盖的列上。
- 如果没有定义唯一约束，语句会报错或静默变成普通 INSERT（取决于 SQL mode）
- 冲突判断基于整个唯一索引，不是单个字段。比如联合唯一索引
(a, b)，只有a和b同时重复才会触发 UPDATE -
REPLACE INTO看似类似，但本质是 DELETE + INSERT，会引发自增 ID 跳变、外键级联删除等副作用，不推荐替代
怎么写安全可靠的 ON DUPLICATE KEY UPDATE 语句
核心是明确“什么算存在”和“哪些字段要更新”。典型写法：
INSERT INTO users (id, name, email, updated_at) VALUES (123, 'Alice', 'alice@example.com', NOW()) ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email), updated_at = NOW();
-
VALUES(col)是 MySQL 特有函数，返回本次 INSERT 中该列的原始值，避免重复写字面量或变量 - 不建议在 UPDATE 子句中直接写
name = 'Alice'，容易因参数拼接出错或 SQL 注入（尤其用字符串拼接构造 SQL 时） - 更新字段不要包含主键或唯一键本身（如
id = VALUES(id)），MySQL 允许但无意义，还可能干扰优化器 - 如果只想更新时间戳而不改其他字段，UPDATE 子句可以只写
updated_at = NOW()，其余字段保持原值
常见踩坑点：NULL、自动递增和影响行数
这个语句的行为和直觉有偏差，尤其在边界场景下：
- 当插入值为
NULL且对应列为允许 NULL 的唯一索引时，MySQL 认为多个NULL不冲突（标准 SQL 中 NULL ≠ NULL），所以不会触发 UPDATE —— 这常被误认为“没生效” - 自增主键（
AUTO_INCREMENT）在触发 UPDATE 时仍会预分配一次 ID，即使最终没用上。高并发下可能导致 ID 空洞，但不影响数据一致性 - 返回的“受影响行数”有三种情况：
1（新插入）、2（更新已有行）、0（新插入但所有字段值与原记录完全相同，MySQL 5.7+ 默认不计为变更）。应用层不能仅靠行数判断是否发生了实质更新 - 如果唯一索引包含可空列，又想用
NULL做业务标识（比如“未绑定邮箱”），建议用特殊字符串（如'<null>'</null>）或默认值替代，避开 NULL 比较陷阱
替代方案对比：INSERT IGNORE vs REPLACE vs MERGE？
MySQL 没有标准 MERGE 语句（8.0.19+ 的 REPLACE 仍是 DELETE+INSERT）。三者差异很实际：
-
INSERT IGNORE：遇到重复键只跳过，不报错也不更新，适合“有就不管，没有才加”的场景 -
REPLACE INTO：先尝试 DELETE 冲突行，再 INSERT 新行。如果该行有外键被引用（ON DELETE RESTRICT），会直接失败；如果有触发器，DELETE 和 INSERT 各触发一次 -
ON DUPLICATE KEY UPDATE：原子性更好，只锁一行，不改变自增计数器（除了预分配），也避免外键级联风险。它是真正意义上的“UPSERT”
真正需要“存在即更新”的逻辑时，别绕弯——确保唯一约束建对，然后老实用 ON DUPLICATE KEY UPDATE。复杂条件（比如“存在且状态为 draft 才更新”）得用 INSERT ... SELECT ... ON DUPLICATE KEY UPDATE 配合子查询，或者干脆拆成 SELECT + 条件判断 + INSERT/UPDATE，别硬塞进一条语句里。
