MySQL不支持单条语句混合INSERT和UPDATE，唯一可靠方案是INSERT ... ON DUPLICATE KEY UPDATE，其依赖唯一约束判断存在性，批量操作需注意索引、注入、包大小及触发器行为。
MySQL 不支持“一条语句既 INSERT 又 UPDATE”，但可以通过 INSERT ... ON DUPLICATE KEY UPDATE 实现「存在则更新、不存在则插入」的原子行为，本质是一条语句完成两类操作。
为什么不能直接用 INSERT + UPDATE 混合写法
MySQL 语法不允许在单条语句中并列执行 INSERT 和 UPDATE；REPLACE INTO 看似能覆盖，但它底层是「DELETE + INSERT」，会丢失自增 ID、触发两次触发器、且不保留未指定字段的原值——这和真正意义上的“更新”不同。
真正可靠、高效、符合 ACID 的方案只有两个：INSERT ... ON DUPLICATE KEY UPDATE（推荐）或 INSERT ... SELECT ... UNION ALL ... ON DUPLICATE KEY UPDATE（批量场景）。
INSERT ... ON DUPLICATE KEY UPDATE 必须满足的条件
该语句能生效，依赖唯一性约束（UNIQUE 或 PRIMARY KEY）来判断“是否已存在”。没有它，所有行都会当作新记录插入，ON DUPLICATE KEY UPDATE 部分完全不会执行。
-
id字段必须有PRIMARY KEY或UNIQUE约束（例如ALTER TABLE myTable ADD UNIQUE (id);） - 若用联合唯一键（如
UNIQUE (user_id, type)），则VALUES中必须提供全部组合字段 - 更新目标列不能是唯一键本身（比如
ON DUPLICATE KEY UPDATE id = VALUES(id)是无效且危险的） - 所有
VALUES()中的字段值类型要与表定义严格匹配，否则可能隐式转换失败或截断
一次插入/更新多行的写法示例
这是最常用、最安全的批量 upsert 场景：
INSERT INTO myTable (id, _RiskName, _Control) VALUES (1, 'vala', 'ctrla'), (2, 'valb', 'ctrlb'), (3, 'valc', 'ctrlc') ON DUPLICATE KEY UPDATE _RiskName = VALUES(_RiskName), _Control = VALUES(_Control);
说明：
-
VALUES(_RiskName)表示“本次 INSERT 中对应位置的值”，不是函数调用，是 MySQL 特殊语法 - 如果某行
id=2已存在，则只更新_RiskName和_Control；如果不存在，就整行插入 - 若需在更新时做逻辑判断（比如只当新值非空才覆盖），可改用
IF(VALUES(_RiskName) != '', VALUES(_RiskName), _RiskName) - 该语句返回的
ROW_COUNT()：插入 2 行 + 更新 1 行 → 返回 3；若全为更新，则返回 1（MySQL 8.0+ 默认行为）
容易被忽略的坑
实际部署时，这几个点最容易出错：
- 没加唯一索引却以为能触发更新——查
SHOW CREATE TABLE myTable;确认UNIQUE KEY或PRIMARY KEY存在 - 用字符串拼接构造 SQL（尤其 PHP/Python 拼接数组），导致 SQL 注入或引号错乱；务必用预处理（如 PDO 的
bindValue）或服务端安全转义 - 批量数据超长（如 5000 行），触发
max_allowed_packet截断；建议单次控制在 500–1000 行以内，或改用临时表 + JOIN 更新 -
ON DUPLICATE KEY UPDATE不会触发INSERT触发器的AFTER INSERT，但会触发AFTER UPDATE—— 如果业务逻辑依赖触发器，得提前验证行为
真正难的不是写对语法，而是确认主键/唯一键设计是否覆盖了你的业务“存在性”判断逻辑。比如用 email 做唯一键，但用户允许换邮箱，那这个“存在性”就不可靠了。
