用 INSERT ... ON DUPLICATE KEY UPDATE
实现高效批量更新
当表有唯一索引（
UNIQUE或
PRIMARY KEY）时，这是 MySQL 最推荐的批量更新方式。它本质是“存在则更新，不存在则插入”，但若你只关心更新已有记录，可配合
WHERE过滤或确保传入的主键/唯一键全部已存在。
常见错误是忽略冲突字段判断：比如用
ON DUPLICATE KEY UPDATE里却写
name=VALUES(name)而没检查
1000行，超量易触发
max_allowed_packet错误或锁等待加剧
VALUES(col)引用的是当前这一行 VALUES 子句中的值，不是原表值
INSERT INTO users (id, name, email, updated_at) VALUES (1, 'Alice', 'a@example.com', NOW()), (2, 'Bob', 'b@example.com', NOW()), (3, 'Carol', 'c@example.com', NOW()) ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email), updated_at = VALUES(updated_at);
用 UPDATE ... JOIN
批量更新多行（无唯一键场景）
当没有合适唯一键、或需基于另一张表/临时数据源更新时，
UPDATE ... JOIN更可控。它不依赖冲突机制，而是显式关联后逐行更新，适合复杂条件或中间计算。
性能陷阱在于：若
JOIN的右表（如临时表或子查询）未建索引，MySQL 可能走全表扫描，使更新变慢十倍以上。 务必对
JOIN条件列（尤其是右表）建立索引，例如
tmp_update(id)避免在
JOIN中使用非确定性函数（如
NOW()），会导致执行计划不稳定 可用
CREATE TEMPORARY TABLE预载更新数据，比子查询更易优化
UPDATE users u
JOIN tmp_update t ON u.id = t.id
SET u.name = t.name,
u.status = t.status,
u.updated_at = NOW();
批量更新时锁与事务的隐性开销
MySQL 的
UPDATE默认加行级
SELECT FOR UPDATE类似锁，批量操作会持续持有这些锁直到事务结束。若一次更新 5000 行且事务未及时提交，可能阻塞其他读写，甚至触发
Lock wait timeout exceeded。
典型误操作是把整个批量更新包在一个大事务里执行，尤其在应用层循环拼 SQL 时容易忽略 commit 控制。
按主键范围分片更新，例如每次处理id BETWEEN 1000 AND 2000每批控制在 500–1000 行，并显式
COMMIT，避免长事务 确认隔离级别：高并发下
REPEATABLE READ可能因间隙锁扩大锁定范围
替代方案：REPLACE INTO
和它的危险点
REPLACE INTO看似简洁，但它底层是“删 + 插”，会引发主键自增偏移、触发器重复执行、外键级联异常等问题，生产环境应避免使用。
最隐蔽的问题是：如果表有自增主键且未在
VALUES中显式指定，
REPLACE会分配新 ID，导致主键跳跃，后续业务依赖连续 ID 的逻辑可能出错。
REPLACE不是原子更新，DELETE 和 INSERT 分两步，期间可见性有空窗 不会触发
ON UPDATE CURRENT_TIMESTAMP自动更新时间戳 日志体积翻倍（binlog 记录 DELETE + INSERT），主从延迟风险升高 实际批量更新的关键不在语法多炫，而在于明确数据来源是否可靠、冲突策略是否符合业务语义、以及锁粒度是否可控。哪怕用了最短的 SQL，如果没压测过 10 万行下的锁表现，上线后就容易卡住整个订单表。
